floooh
Other build systems, SCons
Hi Floooh,
Definitely considering to adopt fips for my build processes/workflow, very handy! I'm experimenting right now with Oryol and feel like it has great first-class portability and modularity and yet doesn't impose a certain game engine design on you.
Anyway back to Fips, I work on some codebases which uses SCons as their primary build systems. In the past I've attempted to make a CMake version of them but the codebases of these are very complex with many dependencies (often these dependencies are CMake fortunately to fips'ify) and is constantly being updated by other developers which would make this not feasible. Are there parts of Fips which make this process easier? Maybe I'm over-thinking this, but it would be neat to know how you're dealing with these things already. Making some fips cmake wrapper which invokes the scons build script sounds like this would do the job.
Cheers!
Hi, so far I've always built a new 'fipsified' cmake file for projects with different meta-build-systems. Simply invoking scons will often not work because the a fips project needs to be imported and integrated with other projects, which use cmake files. I'll keep the idea in mind, but can't promise a quick solution :)
I have developed a little standard routine over time for fipsification:
- first build and explore the project with it's native build system to get familiar with it, and find out what files and compiler options are needed
- create a new wrapper project on github, run 'fips init' on it and then add the other project as submodule
- populate the fips CMakeLists.txt file, test, repeat...
For some projects with very complex build systems I simply had to give up though (e.g. SDL), or libcurl. In the case of libcurl I cheated and simply created a fips-wrapper that has just the headers and precompiled libs (see here: https://github.com/floooh/fips-libcurl)
Actually a lot of my issues with this particular codebase I was trying to convert to CMake was to keep in-sync with it, but the submodule approach might solve that issues and just house the CMake files in there instead of having a custom fork of the project. Not to steer the conversation, but here is one of the projects in particular which is SCons-heavy, with lots of open source VFX library dependencies: Gaffer
Your code-generators in python kind of aligns with my idea to generate headers and shader code, but with Gaffer, as it's essentially a nice node GUI to build procedural python scripts to generate various stuff (particularly I want to write a procedural asset pipeline with it, notably shaders and procedural geo/textures offline and feed it into a game runtime).
Hmm I see, trying to integrate another complex project with it's own myriad of dependencies will be tricky with the typical 'fipsify approach'.
There's several ways I could think of, all would still be based around the "create a fips wrapper with external cmake files instead of forking", but none of these is particularly elegant ;)
- First, cmake can call external tools in various ways: execute_process() runs during the 'cmake run' when building the project files, and there are a few ways to add custom build steps which also call into external tools. May be these would allow to call scons, and build the result into link libs, which could than be picked up by the cmake generated build scripts.
- Or: fips allows to add 'custom verbs' python scripts, which can then be executed by invoking './fips [verb]', I use this in Oryol to build the samples webpage or build and run tests. You could wrap the entire Gaffer build process in such a custom verb, so that it runs scons, and 'pre-compiles' Gaffer into a number of link libs, which than can be picked up by the normal cmake build process.