I really liked the vibe/design/portability of luau because I'm also in the middle of gradually porting the project's backend to wasm (WIP) and would eventually like users to be able to experiment with their own physics components etc. in a browser without a server-side backend and eventually provide a safe-to-distribute model format that includes scripted components.
Because I deploy to 3 (soon, 4) platforms, the way in which I handle dependencies is to provide a separate source-build of all of dependencies in third_party. The directory contains its own CMakeLists.txt, which uses ExternalProject_Add to build+install each dependency into a unified directory that can then be added to the CMAKE_PREFIX_PATH of some downstream project (for me, it's opensim-creator). The idea is that some dependencies can be disabled, layered over the OS-provided ones, etc. without having to have custom find_package steps in opensim-creator (i.e. it can all be handled from the top-level build bash script or similar).
Other PRs Like this
1166 , which isn't handy for me because you can't find_package in a downstream project
926, which I gracefully ripped off and changed a little bit based on personal preferences. Heavy credit should be given to #926 . My (sometimes, taste-based) changes from it were:
I don't hard-code the installation dirs as much and try to fallback to cmake's defaults or ${CMAKE_INSTALL_LIBDIR} etc.
The install-related steps are closer to where the targets are configured, rather than being in a separate location, to minimize having to separately check if(BUILDING_CLI)-type flags
I don't version it
Testing I've Completed
I made these changes and now I can just find_package in my downstream branch. I'll report back once I have a branch building on all 4 (Win/MacOS/Linux/Emscripten) platforms.
This isn't a PR you guys should necessarily merge, but just another datapoint on how to (potentially) handle installation packaging.
Background
Just for context, my use-case is that I'm experimenting with adding some sandboxed scripting to:
I really liked the vibe/design/portability of luau because I'm also in the middle of gradually porting the project's backend to wasm (WIP) and would eventually like users to be able to experiment with their own physics components etc. in a browser without a server-side backend and eventually provide a safe-to-distribute model format that includes scripted components.
Because I deploy to 3 (soon, 4) platforms, the way in which I handle dependencies is to provide a separate source-build of all of dependencies in
third_party. The directory contains its ownCMakeLists.txt, which usesExternalProject_Addto build+install each dependency into a unified directory that can then be added to theCMAKE_PREFIX_PATHof some downstream project (for me, it'sopensim-creator). The idea is that some dependencies can be disabled, layered over the OS-provided ones, etc. without having to have customfind_packagesteps inopensim-creator(i.e. it can all be handled from the top-level build bash script or similar).Other PRs Like this
1166 , which isn't handy for me because you can't
find_packagein a downstream project926, which I gracefully ripped off and changed a little bit based on personal preferences. Heavy credit should be given to #926 . My (sometimes, taste-based) changes from it were:
${CMAKE_INSTALL_LIBDIR}etc.install-related steps are closer to where the targets are configured, rather than being in a separate location, to minimize having to separately checkif(BUILDING_CLI)-type flagsTesting I've Completed
I made these changes and now I can just
find_packagein my downstream branch. I'll report back once I have a branch building on all 4 (Win/MacOS/Linux/Emscripten) platforms.