openFrameworks

[dimitre]

First of all thank you very much by putting together everything needed to run and distribute a basic openFrameworks app.
I'm now using a very similar configuration you sent me, I've put a copy here
https://gist.github.com/dimitre/4339fda7bef0d7ff373c2da2f5d2c25f

but I'm having a specific issue, the app bundle can't access data folder, and It seems data folder is being copied to Contents/MacOS instead of Contents/Resources where openFrameworks traditionally store data folder.

is there some way of changing this? thank you

[rewrking]

Yeah... so this is a weird issue. I totally agree with you that it should be in Resources.

On the one hand, copyFilesOnRun was intended for files and paths that need to be relative to the executable at runtime - like using LoadLibrary on windows or some code that doesn't respect the working directory. There's some dodgy code around that feature when it comes to bundling - anything defined by copyFilesOnRun will be placed in the same path as the executable, so that's ultimately what you're seeing. It certainly needs some tweaks.

On the other hand... I found a questionable piece of code in open frameworks - ofFileUtils:31-35. This seems to be getting the current executable directory, and then looking for the data folder 3 parents up. Do you happen to understand why it was written that way?

I was testing with the box example, and the texture did not load in either the MacOS or Resource folder, however, if I edited that ofFIleUtils block to just use "data/", the texture will load if data is in the MacOS folder (and during development with buildrun)

[dimitre]

I think if the data is not meant to be inside macOs app bundle, it is 3 folder parents up, because bundle is actually a folder
like IsoLuz.app/Contents/MacOS/IsoLuz
so 3 parents up equals to the same folder the app bundle is in.

I suppose it just doens't use this relative path if data folder is copied inside.
There is a commented out option in Project.xcconfig

OF_BUNDLE_DATA_FOLDER = 1

which you can set the project to copy the data folder, so it is copied to Resources.

[dimitre]

I'm proposing a modification where all paths for file input / output are related to the data folder, independent where it is, always setting current_directory to data folder. what do you think about this idea?

[rewrking]

Wow yeah it seems like the data folder outside the bundle convention has been around for a while (found some discussions from '08). Can't say I agree with doing that though - I think app bundles should contain everything required to run, and that should be 95% of use cases.

So the easy way to get this working would be to have this folder structure:

+ bin/data/ -- or just data/
+ src/
chalet.json

in ofApp::setup() call:

ofSetDataPathRoot("bin/data/");

take out "copyFilesOnRun[:macos]": "examples/3d/cameraParentingExample/bin/data"

in distribution.ofBoxExample add:

"include": [
  "bin" // or "data" - whatever the root folder is
]

You would need to adjust your other paths that point to the of libs

Might be time to just make a openFrameworks example repository...

[dimitre]

Yeah! and it would be great to have openFrameworks separated in a different project, maybe a chalet.json in the same project folder pointing to the OF project like this

	"of-chalet": {
		"kind": "chaletProject",
		"condition": "[:!windows]",
		"location": "../../..",
		"recheck": false
	},

here the three parents up means openframeworks/apps/myApps/testApp folder points to openFrameworks folder.

[rewrking]

The only thing I would change in that example is "location": "../../.." to "location": "${env:OPEN_FRAMEWORKS_PATH}" so the project is independent of the machine.

Package management would be super nice here though - imagine just going "requires": ["of::static"] or something. Maybe one day...

[dimitre]

Yeah indeed! I want to try to port some OF addons to Chalet build system, and maybe give a try on apothecary, which is a compilation of scripts to build all the libraries for all the supported OS.

[dimitre]

Chalet is GREAT!
I've been building over the sample file you sent me. now I'm using variables to addons and include paths. I can even use GLOB + variables, so it is super useful.

here is my sample file today : https://gist.github.com/dimitre/5395276a925952327d8a194bb2d66645

Two things I'm having issues right now:
it would be great to be able to use GLOB in staticLinks paths, now I'm using like this

		  "staticLinks": [ 
			"open-frameworks",
			"addons/ofxAssimpModelLoader/libs/assimp/lib/osx/assimp.a"
			]

and it would be great to use "addons/{${var:addons}}/libs/**.a"

And the other thing is : for ofxSyphon addon it includes a custom Framework. so it would be great to know how to include a custom framework in an app.
Thank you for the great work

[dimitre]

I'm now using a separate Chalet project for OF and for the project, my last files are here:
OF
https://gist.github.com/dimitre/d6cedc75a51e8cf4bcd564f862e978b7
Project
https://gist.github.com/dimitre/278a61801aafd36267ff4f2ff224b8e4

Everything is working great!
In the project I've made it work by linking in absolute path the compiled .a library, but I'm wondering if is there a better way of using a chalet project as externalDependencies of another

[rewrking]

So this is the plan at the moment - how rust's cargo does things, or as close as possible:

1. In-project transitive dependencies (require: of:static or something):
   Package Management 1 - In-Project #165

2. "Local to machine" package repository - a package repository is defined to a folder, and there's some kind of folder structure to handle various packages and versions. of:static gets specified in packages or something.
   Package Management 2 - Local to Machine #167

3. "Primary repository" for packages aka a git repository that does the same thing as the local version above, but does all the network stuff and caching so you're only getting what you need. At this point, "local to machine" is just a cache of the remote packages you need.
   Package Management 3 - Primary Repository #166

4. "Mutliple respositories" so you can have your own repository with your own stuff if you so desire.
   Package Management 4 - Multiple Repositories #168

[dimitre]

I'm now working in a super small project, inspired by Chalet. and built using Chalet.
it is a command line project which builds an openFrameworks project from a recipe.
I've choose to use YAML file format instead of Json because two things were bothering me in Json format. It is not easy to comment out lines properly, and sometimes you have to deal with trailing commas too.

it is work in progress yet
https://github.com/dimitre/ofbuild/
and I'm looking forward to Chalet 0.6.0 release to automate releases in github actions

[dimitre]

I've recently worked in OF projectGenerator to be able to generate complete VSCode templates.
Wondering if I try to generate a Chalet template generator also. Probably I'll be asking lots of questions if I try this.
Thank you

[rewrking]

Sounds cool, but it is probably too early for something like that. I still need to tackle packages so it can basically inject the libDirs, includeDirs, etc transitively. It would simply make things a lot easier, especially for a big framework like this that is only meant as a static library.

Keep in mind this is basically the template right now:

https://github.com/chalet-org/chalet-example-openframeworks/blob/main/box/chalet.json

If I can trim that down to an OF package declaration and a one-line import, it would be a huge improvement.

[dimitre]

Hello @rewrking I'm now trying to build some Openframeworks dependencies using Chalet, and I'm having some difficulties in packaging process. Project is in this repo: https://github.com/dimitre/ofChalet

This is commented out in the repo, but it seems Chalet can't add one .a library like this:

		"freetype": {
			"kind": "archive",
			"condition": "[:macos]",
			"format": "zip",
			"include": [
				"${externalBuild:freetype}/*.a",
				 "${external:freetype}/include"
			]
		}

if I remove the "*.a" and just left the ${externalBuild:freetype} folder I can see the .a is there.
Thank you

[rewrking]

Hmmm, it looks like just the glob pattern in that case doesn't work. I'll have to look into it. The following does work:

"${externalBuild:freetype}/libfreetype.a"

// cross-platform  - for instance, it would resolve to freetype.lib on msvc
"${externalBuild:freetype}/${ar:freetype}" 

It does just place the .a file in the root, which may not be ideal. I do have to revisit archive targets at some point in the future to make it more clearer.

[dimitre]

Thank you! great! it would be great to be able to optionally select a folder to be added, so I could reproduce the OF libraries structure of folders "include" "lib/os" and "license"

[rewrking]

Yeah, it's not super intuitive. I opened #365 for the glob pattern issue (should get to it later this week), and #366 for the larger folder mapping issue (a future v0.8.x release). My original thinking was that for every archive, there would be a bundle anyway, which allows for a subfolder, but I think both target types should have the same interface. You can see this pattern in the chalet-example-sharedlib example. It basically has a bin bundle and a lib bundle, and it would be certainly nicer to be able to combine the two

[rewrking]

v0.7.21 is released. It has the glob pattern fix for include in archive targets.