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.

[dimitre]

I'm trying to build OpenFrameworks libraries (apothecary) project alternative using Chalet, but I'm finding some difficulties in the bundle process.
I think (not sure) the distribution phase is verifying valid paths from files that still don't exist (like static libs that will be compiled and .a generated) and treating as an error.
if you have the time to check here is the action result
https://github.com/dimitre/ofChalet/actions/runs/11261371449/job/31314665561

and json file here
https://github.com/dimitre/ofChalet/blob/main/chalet.json
Thank you

[rewrking]

I'll dig into this later in my evening, but the crux of the issue is that there is an initialization step where all of the glob patterns and substitution variables get expanded. It's clearly getting called before the build phase, and I don't remember why that is - so I have to find that out again.

Globbing the includes in the distribution presents some odd problems. For example, if you had an app bundle target that used a glob pattern for a static or shared library in a external build folder, and exported the xcode project, it would not get resolved at that point in time, so it would be excluded in the xcode project file - even if the expansion order got fixed.

If you need a fix right this second, just don't use glob patterns in the distribution includes:

"${externalBuild:freetype}/${ar:freetype}"

[dimitre]

Hey @rewrking can you please take a look on this project to see if there are more smart ways of achieving the same?
https://github.com/dimitre/ofChalet/

Maybe a way of templating repeptitive settings? abstracts? thank you

[rewrking]

You can technically take out the following:

"defines[platform:macos]" : [
  "CMAKE_OSX_DEPLOYMENT_TARGET=10.9",
  "CMAKE_OSX_ARCHITECTURES=x86_64;arm64"
]

And pass the version and arches via command-line:

chalet build -t apple-llvm -a universal --os-target-version 10.9

Note: universal = x86_64 & arm64

You can then stick that in a "bootstrap.sh" script, as you'd have to write it out in every cmake target otherwise. You actually shouldn't be checking in .chaletrc to git, as those are meant to be settings specific to the current build and machine you're building on.

If you want to keep the deployment target enforcement in chalet.json, the alternative right now is to add variables:

{
"variables": {
  "osxVersion": "10.9",
  "osxArch": "x86_64;arm64"
}
}

and then reference them like so:

"defines[platform:macos]" : [
  "CMAKE_OSX_DEPLOYMENT_TARGET=${var:osxVersion}",
  "CMAKE_OSX_ARCHITECTURES=${var:osxArch}"
]

Abstract target settings can only be used with executable, staticLibrary and sharedLibrary.

[dimitre]

I'm now trying to cross compile in Raspberry PI using github actions.
this doesnt' work:

chalet bundle -t aarch64-linux-gnu
chalet bundle -t arm-linux-gnueabihf

any ideas?

action test:
https://github.com/dimitre/ofChalet/actions/runs/12022850868/job/33515747671

[rewrking]

I think you're just missing -gcc. Try:

chalet bundle -t aarch64-linux-gnu-gcc
chalet bundle -t arm-linux-gnueabihf-gcc

Additionally, you can use the shorthand:

chalet bundle -t gcc -a arm64 
chalet bundle -t gcc -a armhf 

chalet bundle -t llvm -a arm64 
chalet bundle -t llvm -a armhf 

... which is easier to remember :)

[dimitre]

I have other issue now. this line works for libusb

      - ${externalBuild:${name}}/*.a

and this other one doesn't

      - ${externalBuild:${name}}/${ar:libusb}

Both commands run ok, one bundle library other not (for this lib, other libs are working great with something like ${externalBuild:${name}}/${ar:${name}}
it would be great if chalet "echoed" this variables to see where exactly they are pointing.

it is this repo / folder
https://github.com/dimitre/ofLibs/blob/main/libusb/chalet.yaml

PS: I invited you to the repo and feel free to change anything there

[rewrking]

I'll look it over at some point tomorrow morning (+14 hrs or so). Had a busy day. You might just need:

${externalBuild:${name}}/${ar:usb}

The lib prefix gets added based on the toolchain (clang/gcc/mingw)

[rewrking]

I'll add a sub-command that (chalet check maybe?) that echoes the processed build file for that particular platform, and will have some kind of output for expanded variables too.

[rewrking]

This is done (the first pass anyway):

#386

I have one more thing I want to add tonight, and then I'll push a build out.

[dimitre]

other question: I have some github runners and I like to use environment variable to have ccache as CMAKE_CXX_COMPILER_LAUNCHER, like this:

env:
  CMAKE_CXX_COMPILER_LAUNCHER: ccache

they work great directly compiling cmake projects, but I'm not sure chalet forwards environment variables to CMAKE invocations. Does it?

[rewrking]

This should be set already if you pass --compiler-cache, and your ccache executable is found in Path (it will show up in .chaletrc).

If you pass --show-commands, you should see it in the CMake invocation:

C:/Program Files/CMake/bin/cmake.exe -G Ninja -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Release -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_MAKE_PROGRAM=C:/ninja/ninja.exe -DCMAKE_C_COMPILER=C:/msys64/mingw64/bin/gcc.exe -DCMAKE_CXX_COMPILER=C:/msys64/mingw64/bin/g++.exe -DCMAKE_RC_COMPILER=C:/msys64/mingw64/bin/windres.exe -DCMAKE_CXX_COMPILER_LAUNCHER=C:/ccache/ccache.exe -DCMAKE_LIBRARY_ARCHITECTURE=x86_64-w64-mingw32 -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON -S C:/Users/Rew/dev/new-project/chalet_external/freetype -B C:/Users/Rew/dev/new-project/build/x86_64-w64-mingw13_Release/ext.freetype

[dimitre]

Great one! I have some suggestions for Chalet (pick only if they resonate with the project)
it would be great to add --compiler-cache and --show-commands to the help (chalet --help)
and maybe add Chalet version to the help command, maybe something like
Chalet 0.8.0 - A cross-platform JSON-based project & build tool

[dimitre]

another suggestion:
sometimes we have duplicated entries on CMAKE definitions and chalet errors which is great!
but the error is a little bit cryptic : "One of the subschemas are required for 'freeimage' (per 'oneOf'), but none matched."
it could return a better error message

[rewrking]

That comes from the JSON schema validator. It's a can of worms. Basically even though you're using yaml, it internally gets converted to JSON, so that it can be validated by the schema validator. The validator library originally throw exceptions with even more cryptic messages, so I had to fork it, and have it return an enum so that I could write the validation messages myself (shown in the link).

"oneOf" is basically a way to say "this json node can be one of an array of sub-schemas," so I think you added two different types somehow. I'd have to look at it to understand how it triggered. Do you have an example of what you did?

[dimitre]

oh no worries. I just thought the error message was yours.
you can trigger by duplicating exactly any cmake definition, like:

      - GLM_ENABLE_SIMD_SSE4_2=ON
      - GLM_ENABLE_SIMD_SSE4_2=ON

it is great it doesn't allow duplicate. in fact the VSCode plugin is great in validating JSON.
I'm now changing editor to ZED and trying to make an OF build system there. lovely editor

[rewrking]

Ah okay that makes sense. I meant it was technically my error message, but it's actually correct if you read the schema - defines has two schemas - one where you define a single string, and the other where you define an array. The array one requires no duplicates (uniqueItems in the json schema), so when it fails, the error message bounces to the schema type of defines which is oneOf.

I have to dig into this. What I generally like to do is compare what error message comes up (if any) in VS Code, and try to match that.

[rewrking]

I'll have a fix for this in the next build. The new output looks like this:

>  Reading Build File [chalet.json] ...
ERROR: Failed to validate the file: chalet.json
ERROR: The 'defines' array must have unique items, but duplicates were found.
ERROR: The 'defines' property failed to match one of its required subschemas.

There's technically a 2nd subschema error here that gets hidden - it's really confusing to have both otherwise. The other one is:

ERROR: An invalid type was found for 'defines'. Found array

Basically, it's for the first subschema - it's looking for a string type, but find an array instead (which is meant to match the 2nd subschema). I might fix this later, but for now I want to move on... 😂

[dimitre]

just wondering if something like this can be useful for Chalet project:
or if there is something similar already

    defines[arch:arm]:
      - GLM_TEST_ENABLE_SIMD_NEON=ON
    defines[arch:x86_64]:
      - GLM_ENABLE_SIMD_AVX=ON
      - GLM_ENABLE_SIMD_AVX2=ON

[rewrking]

You should be able to use that already, but with architecture:

    defines[architecture:arm]:
      - GLM_TEST_ENABLE_SIMD_NEON=ON
    defines[architecture:x86_64]:
      - GLM_ENABLE_SIMD_AVX=ON
      - GLM_ENABLE_SIMD_AVX2=ON

I was on the fence about abbreviating it for whatever reason, and decided against it because "architecture" was used in other areas.

[dimitre]

thank you!

[dimitre]

one more question: if I cross compile let's say ubuntu 24.04 runner (probably x86_64 processor) and cross compiling with toolchain aarch64-linux-gnu-gcc which results I'll have in [architecture] selector?

[dimitre]

I'm supposing it is returnin x86_64, because this action is failing with some intel intrinsics, only on arm cross compiling
https://github.com/dimitre/ofLibs/actions/runs/12476099437/job/34820433462

[rewrking]

So in that chalet.yaml for GLM:

Take out the last block of defines (or comment it out), then on line 51, change defines[architecture:arm] to defines[architecture:armhf], since you're asking for the fpu version. The CMake target should resolve the simd defines correctly.

If you want to share it with aarch64, you can write:

defines[architecture:{armhf,aarch64}]: # or arm64, if you prefer

Also, remember you can use chalet -t gcc -a (arm64/armhf) build, and it will resolve to the same cross compilers. No need to pass -t arm-linux-gnueabihf-gcc

[dimitre]

quick question, is there a way of passing parameters to cmake, like -GXcode ?

[rewrking]

For -G in CMake targets, no. If you need the Xcode generator specifically for something, you should call it from a script.

[dimitre]

Thanks. What I'm trying to achieve is bulding a static library for iphoneos (arm64), and another for iphonesimulator(x86_64 & arm64, fat lib) and then join both in a xcframework. it is already working here:
https://github.com/dimitre/ofLibs/blob/main/assimp/ios.sh

it would be great to be able to pass parameters to cmake, this way I could keep all CMAKE definitions made for other platforms for this special case. the xcframework step can be made in a separate script.

[dimitre]

This is one feature it would be great if you consider, some way of passing this parameter to CMAKE
The GREAT usefulness of Chalet is making one list of general rules for building libraries, then making only needed exceptions for platforms. if we can have this for the static lib generation of this script all CMAKE invocation is handled by Chalet
https://github.com/dimitre/ofLibs/blob/main/assimp/ios.sh

[rewrking]

I don't really see it that way. The generator set for CMake targets is tied to the toolchain and build strategy set by Chalet. If you need the Xcode project, just generate it through a script and pass in the build paths as arguments. This is too niche a use case otherwise right now.

[dimitre]

in this project here
https://github.com/dimitre/ofLibs/blob/main/curl/chalet.yaml
I'm trying to set target to macOS 11.0, like this

      - DEPLOYMENT_TARGET=11.0
      - CMAKE_OSX_DEPLOYMENT_TARGET=11.0

and the verbose output shows the invocation is setting this variable twice, the first as 11.0 and the second as 14.5
Is this a Chalet problem or Curl cmake? Thanks

/opt/homebrew/bin/cmake -G Ninja -DCMAKE_ARCHIVE_OUTPUT_DIRECTORY=lib/ -DCMAKE_BUILD_TYPE=Release -DUSE_NGHTTP2=OFF -DUSE_LIBIDN2=OFF -DCURL_USE_LIBSSH2=OFF -DCURL_USE_LIBPSL=OFF -DCURL_DISABLE_LDAP=ON -DBUILD_CURL_EXE=OFF -DBUILD_EXAMPLES=OFF -DBUILD_SHARED_LIBS=OFF -DCMAKE_USE_OPENSSL=ON -DCMAKE_INSTALL_INCLUDEDIR=include -DCMAKE_INCLUDE_OUTPUT_DIRECTORY=include -DUSE_RESOLVE_ON_IPS=OFF -DENABLE_ARES=OFF -DENABLE_STRICT_TRY_COMPILE=ON -DHAVE_GETPASS_R=0 -DCMAKE_CXX_EXTENSIONS=OFF -DCMAKE_IGNORE_PATH=/opt/homebrew -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCURL_STATICLIB=ON -DBUILD_STATIC_LIBS=ON -DENABLE_UNICODE=ON -DCMAKE_INSTALL_PREFIX=Release -DHAVE__FSEEKI64=OFF -DCMAKE_USE_SYSTEM_CURL=OFF -DENABLE_ARC=ON -DCMAKE_POSITION_INDEPENDENT_CODE=TRUE -DENABLE_VISIBILITY=OFF -DENABLE_UNIX_SOCKETS=OFF -DHAVE_LIBSOCKET=OFF -DCMAKE_MACOSX_BUNDLE=OFF -DCURL_DISABLE_POP3=ON -DCURL_CA_FALLBACK=ON -DCURL_DISABLE_IMAP=ON -DENABLE_WEBSOCKETS=ON -DENABLE_UNIX_SOCKETS=ON -DCURL_BROTLI=OFF -DENABLE_VERBOSE=ON -DENABLE_THREADED_RESOLVER=ON -DCMAKE_OSX_ARCHITECTURES=x86_64;arm64 -DDEPLOYMENT_TARGET=11.0 -DCMAKE_OSX_DEPLOYMENT_TARGET=11.0 -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_MAKE_PROGRAM=/opt/homebrew/bin/ninja -DCMAKE_C_COMPILER=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -DCMAKE_CXX_COMPILER=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -DCMAKE_CXX_COMPILER_LAUNCHER=/opt/homebrew/bin/ccache -DCMAKE_LIBRARY_ARCHITECTURE=arm64-apple-darwin -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON -DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk -DCMAKE_OSX_DEPLOYMENT_TARGET=14.5 -S /Users/d/src/ofLibs/curl/chalet_external/curl -B /Users/d/src/ofLibs/curl/build/arm64-apple-darwin_Release/ext.curl

[rewrking]

I'll have a fix for this shortly. I'm also bumping the chalet version.

[rewrking]

Fixed in v0.8.0. Setting CMAKE_OSX_DEPLOYMENT_TARGET will override what's set from --os-target-version

[dimitre]

Thank you! I've noticed now there is a @dev channel in brew. it points to a removed release

Error: chalet-org/chalet/chalet@dev: Download failed on Cask 'chalet@dev' with message: Download failed: https://github.com/chalet-org/chalet/releases/download/snapshot-v0.8.0-202501142311/chalet-arm64-apple-darwin.zip

[rewrking]

Yeah, something went wrong in the new CI script. I'll fix it manually for now.

Edit: both channels should have 0.8.0 for now. You might need to: uninstall, untap, tap, install

[dimitre]

Allright! all running well locally
github runners still showing last version but I had to disable prerelease=true to it grabs the latest release instead.
now it is showing as 8.0.0

[dimitre]

quick question: to run .sh in Windows do I need Windows Subsystem for Linux installed?
I don't know much about Windows, I'm just checking some windows runners here
https://github.com/dimitre/ofLibs/actions/runs/12816725422/job/35738346017

[rewrking]

You can probably use WSL somehow, but I've found the easiest way is to install Git for Windows or MSYS2 if you have access to the machine. Since you're in CI land though, the best thing to do is probably use a .bat script if you can, and make a [:windows] condition for it. Git comes with a slimmed down version of MSYS2 that does all the shell things. I think Chalet will automatically favor the git installation if it looks for bash on Windows.

[dimitre]

Some libraries like opencv needs cmake --install to generate the correct headers.
I'm using some CMAKE definitions to install to a specific folder and bundle the zip file according to a script

      - CMAKE_ARCHIVE_OUTPUT_DIRECTORY=lib/macos/${env:PLATFORM}
      - CMAKE_LIBRARY_OUTPUT_DIRECTORY=lib/macos/${env:PLATFORM}
      - CMAKE_INSTALL_PREFIX=Release
      - CMAKE_INSTALL_INCLUDEDIR=include

It is already working great, but out of curiosity: do you plan to support CMAKE install?

[rewrking]

I'll look into it. I might just enable --install with a property - "install": true

[rewrking]

I've added this in v0.8.1. It runs a separate call to cmake --install after cmake --build, and installs to ${externalBuild:target}/install.

[dimitre]

Thank you I've finally updated scripts to use install: true
all great here.

[dimitre]

I'm now testing chalet on CI / Windows, and it fails for me even with simple scripts

ERROR: D:/a/ofLibs/ofLibs/libusb/test.sh exited with code: 1

https://github.com/dimitre/ofLibs/actions/runs/12933105553/job/36070926413

Anything I should be doing differently? Thanks

[rewrking]

It's still calling it through C:\Windows\System32\bash.exe with WSL not installed, so this is the same issue as last time. IMO just use .bat files on Windows because they don't require any dependencies.

[rewrking]

You could also write the script in python. That will be cross-platform.

[rewrking]

Otherwise, if you're calling a single command, just use a process target.

[rewrking]

Oh you know what, try this: In your github actions yaml file, add:

defaults:
  run:
    shell: bash

(in the same scope as jobs:)

That might run the bash script correctly on Windows when it gets to the script target. I'm not 100% sure though.

[rewrking]

So I just realized something dumb! The script example repository I've had in chalet-org for the past 3 years was set to private. I've just set it to public if you want to see a slew of scripting examples:

https://github.com/chalet-org/chalet-example-scripts

It's a cross-platform-ish collection of hello world scripts in the various supported languages by chalet. It requires installation of all of the interpreters that get called, so you can comment out the script targets of ones you don't have on a particular platform to try it out.

[dimitre]

Meson

it would be great to have meson build also.
I've tried to build using meson via a bash script but strangely it stops in an error trying to find the linker

  Detecting linker via: `cc -Wl,--version` -> 1
  stderr:
  ld: unknown options: --version 
  clang: error: linker command failed with exit code 1 (use -v to see invocation)

https://github.com/dimitre/ofLibs/actions/runs/13546463809/job/37859195548

And if I run the same script directly in github it works OK.

[rewrking]

I had some issues integrating meson the last time I looked at it, but I'll try to check it out again. Off the top of my head:

• Since it's Python-based, Chalet would be invoking it through python every time meson is called. Emscripten is like this too - it's pretty awkward. Meson might be in a python environment, so that has to be handled correctly.
• There's a lot of top-level abstractions in meson that don't mix quite as well as CMake did, so making a mesonTarget is a little more complicated

Bottom line is I need to research it more. I'm not sure what your specific issue is above is, because I don't know enough about meson.

[rewrking]

Okay, I have all of the boring plumbing stuff done. Fortunately, I didn't need to invoke meson through python (on macOS at least - might have to on Windows). Next, I have to figure out how to tell Meson which toolchain executables to use, so I'm basically at where you are...

[rewrking]

I figured this out, and the meson integration is basically done - I'm probably going to test it for another day to make sure there's nothing broken with it.

The solution to the above was to make an ini file with:

[binaries]
c = /usr/bin/clang
cpp = /usr/bin/clang++

(Note: without xcode-select path - so it's literally the above)

and then pass the ini to meson setup with --native-file (file). So it's a similar mechanism as CMake's toolsets, but there's definitely some weirdness with them - I couldn't find a clean way to pass the target architecture to clang specifically, so I ended up using the native file for that in addition to setting compiler paths. The code for that is here if you're curious:
https://github.com/chalet-org/chalet/blob/main/src/Builder/MesonBuilder.cpp#L225

[dimitre]

suggestion

adding new parameters in chalet --help
--compiler-cache --show-commands

[rewrking]

It's intentionally split up by build commands, so:

chalet --help - top level

chalet build --help - subcommand (has the help for compiler-cache and show-commands)

[dimitre]

Thank you!

[dimitre]

Steps for one platform only

I've just discovered macos has case insensitive file system (not exactly) so in libtess I can include a folder called "Include" with first letter capitalized and it works, on Linux not.
if I try to remove "includes" folder it will remove "Includes" folder in mac, so I need a different step for each platform.

I know the following is ugly, but it is a way of using Chalet variables to achieve what I need:
it is failing because "condition" key is not used there.

  tess2_rm:
    condition: [:!macos]
    kind: process
    path: rm
    arguments:
      - -rf
      - ${external:tess2}/include
  tess2_mv:
    condition: [:!macos]
    kind: process
    path: cp
    arguments:
      - -r
      - ${external:tess2}/Include
      - ${external:tess2}/include

[rewrking]

Change -rf to -r. Does the same thing happen?

[dimitre]

I'm finally back to this problem. changing to -r doesn't help.
Chalet thinks condition is an array

Reading Build File [chalet.yaml] ... 
ERROR: Failed to validate the file: chalet.yaml
ERROR: An invalid type was found for 'condition'. Found array
ERROR: The 'tess2_rm' property failed to match one of its required subschemas.

[dimitre]

I know it is not planned
but the best would be able to write scripts using chalet variables, like:

  tess2_folders:
    kind: script
    shell: bash
    run: |
      if [ -f ${external:tess2}/include ]; then
        rm -rf ${external:tess2}/include
      fi
      cp -r ${external:tess2}/Include ${external:tess2}/include

[rewrking]

First message: if you open the project in VS Code with the Chalet and YAML extensions (I also use Error Lens to inline the errors), you'll see the issue right away:

change it to:

condition: "[:!macos]"

Does the error message you got make more sense now? An array was found, because the string starts with [ (because yaml), but condition only accepts a string. I'd rather have Expected "string" in the Chalet error message, but the json validator library does not provide that level of context in that situation.

Re: inline scripts - you can want that all you want, but I refuse to add support for that (It would get really gross with JSON). Just use:

"my-script": {
   "kind": "script",
   "file[:!windows]": "scripts/script.sh",
   "file[:windows]": "scripts/script.bat",
   "arguments": [
      "${external:tess2)"
   ]
}

and get the argument with:

EXTERNAL_TESS2="$1"

You should really be using batch or powershell on Windows, and bash on mac/linux, and write 2 scripts.

[dimitre]

Opencv difficulties on windows

I'm trying to build some libraries in multiple platforms, this repo has a folder for each lib
https://github.com/dimitre/ofLibs/

the folder opencv fails on github, so I got a windows machine to test.
here is the failing action, probably something related to opencv itself
https://github.com/dimitre/ofLibs/actions/runs/14457765853/job/40544495460

but trying to run local on windows gives me other errors, so I'm suspecting it is related to yaml -> json conversion

ERROR: Uncaught exception: [json.exception.type_error.316] invalid UTF-8 byte at index 13: 0x72

using 0.8.3 on windows 11 (windows powershell)

[rewrking]

Could you delete build and .chaletrc beforehand, just in case?

[dimitre]

done that and libusb built well. I'm trying now other libraries.
it would be great if "chalet clean" could clean those also.

[rewrking]

chalet clean just cleans the current build configuration. It doesn't wipe the entire build folder. I could come up with another command that does though...

Edit: The help description for clean is wrong actually - it says Unceremoniously clean the build folder. but yeah, that's not true. I'll fix that.

[dimitre]

opencv and assimp building now. they are the most complex projects.
I'll be testing on all others libs from ofLibs but it seems to be working great on RC6

[rewrking]

Cool. I'll get the next release out by the weekend. I'm experimenting with Unicode target names on all platforms, so that will hopefully be included as well.

[dimitre]

Meson with other toolchains

I'm testing now meson projects with different toolchains, and some are failing
one of them is trying to call an .exe but it is running in a Linux.
https://github.com/dimitre/ofLibs/actions/runs/14629179252/job/41047873276

[rewrking]

Looks like an error in the meson.build file?

 chalet_external/pixman/meson.build:21:0: ERROR: Could not invoke sanity test executable: [Errno 8] Exec format error: '/home/runner/work/ofLibs/ofLibs/pixman/build/aarch64-linux-gnu_Release/ext.pixman/meson-private/sanitycheckc.exe'.

[dimitre]

Possible regression on 0.8.4?

This used to work well, it is building ok locally on 0.8.3 and failing on CI (0.8.4)
https://github.com/dimitre/ofLibs/actions/runs/14767201471/job/41460889776

[dimitre]

Yes it seems to be fixed. I've noticed another one in bundle step now. I didnt' have time to update local chalet and investigate locally but here is the failing action:
https://github.com/dimitre/ofLibs/actions/runs/14768685623/job/41464883774

[rewrking]

Huh. That's a weird one. I'll look into it.

[rewrking]

I can confirm it's definitely another regression (joy). It's probably some regex pattern that changed. I'll look into it by the weekend.

[rewrking]

Thankfully it was something simple. It's been fixed in 0.8.6

[dimitre]

Comfirmed as fixed
https://github.com/dimitre/ofLibs/actions/runs/14794838009/job/41539524926

[dimitre]

Brew tap.

I wonder why we need to tap / untap when you update. usually it is not needed when you release a new version
something that is helping here is using brew reinstall chalet it seems to update correctly. it would be great to get updates only on general brew update / upgrade

[rewrking]

I've been using brew upgrade chalet for the past few updates without issue.

[dimitre]

excellent. does brew upgrade catch a new version?
BTW I love how you actually print there is a new version available if we are outdated

[dimitre]

I've just noticed to be able to build using meson and setting the proper macos version I should invoke this before invoking meson:

export MACOSX_DEPLOYMENT_TARGET=11.5 

is there a way of setting export "environment " variables so chalet invokes meson with them?
Thanks

[rewrking]

You can use a .env file to define variables in the chalet process environment. So the contents of that file would be:

MACOSX_DEPLOYMENT_TARGET=11.5

Could you send me the meson project? I'm curious if this is something custom in a build file or built into meson

[dimitre]

Sure thing. the repo is this
https://github.com/dimitre/ofLibs/
and the folder is cairo
from my research this is a general meson thing. the only way of defining deployment target.

[rewrking]

https://clang.llvm.org/docs/CommandGuide/clang.html#envvar-MACOSX_DEPLOYMENT_TARGET

Apparently this is built into Clang - this environment variable is used if the build system does not set the deployment target... so because it's not set by meson, it's read by this environment variable.

I'll add something for this... if there's no command-line to tell meson to use the version from --os-target-version, This will get set.

[dimitre]

I've just noticed .env works locally, but doesn't work on CI (github actions)
so I moved to github actions env section and it is building ok now

[dimitre]

I have some difficulties while using Chalet with Meson for cross compiling.
like this:
https://github.com/dimitre/ofLibs/actions/runs/16273898533/job/45948038987
it seems to try to invoke an .exe file sanitycheckc.exe
I've heard it is a linux native file even with this unusual extension. maybe it is only missing execute permission.

[rewrking]

Extension aside, from what I can gather: sanitycheckc was built for aarch64, but meson is trying to run it on a x64 ubuntu runner, so that is why it's giving you the "Exec format error."

[rewrking]

I found this discussion (sounds like it's a lot of noise though): mesonbuild/meson#11784

Also:
https://mesonbuild.com/Release-notes-for-0-54-0.html#skip-sanity-tests-when-cross-compiling

It looks like skip_sanity_checks is the option to set, but it might not work based on those discussions?

[dimitre]

I'm wondering if it is possible to use chalet on windows using msys2.
I'm trying to install a lib that depends on opencv, so maybe it is easier there for cmake find opencv
https://github.com/dimitre/ofLibs/tree/main/stag

[rewrking]

Yes, it's possible. See:

https://www.chalet-work.space/docs/getting-started

under "Adding a C/C++ Compiler" followed by "If using MinGW-w64 (GCC) via MSYS2"

[dimitre]

Nice. I suppose it needs to be compiled from source right?

[rewrking]

You just need a Windows build of Chalet. You can also cross-compile your programs to MinGW from linux.

[dimitre]

Thank you it is already working once I add to the msys2 path.
Fantastic. I'll try to cross compile also

[dimitre]

this is great. in 15 min I had everything set to cross compile to msys2

          - {
              platform: msys2,
              os: ubuntu-latest,
              prefix: mingw-w64-x86-64,
              toolchain: x86_64-linux-gnu-gcc,
              shell: bash,
            }