redguardtoo
Allow the use of different build systems (ex. Ninja)
By default cpputils-cmake uses make, but I think it could not be difficult to allow the user define a different build system. A quick though would be to define a variable (ex: cppcm-build-command) initialed defined to make but the user can change it to other build system that behave like make (ex: ninja).
From its website [1]: "Ninja is a small build system with a focus on speed. It differs from other build systems in two major respects: it is designed to have its input files generated by a higher-level build system, and it is designed to run builds as fast as possible."
I am using CMake with Ninja as build system (CMake -G Ninja) in a very large C++ project, mainly because it is as fast as it says it is; and that it is very easy to integrate with RTags. To get the build commands for RTags you only need to do:
# CMake -G Ninja
# ninja -t commands
and does commands are the one you need for RTags, you can do an script like:
# ninja -t commands | while read i; do /path/to/rtags/bin/rc --compile $i; done
And then you have your project ready to be used with RTags (note that you would need to do the same for every new file added to the project). See the RTags video where they show you this at [2].
[1] http://martine.github.io/ninja/ [2] http://www.youtube.com/watch?v=Zivoc5DH_II
- parse build.ninja
- it's like make
- need scan from the bottom for the targets
- relative path should be converted to absolute path (relative to ninja.build)
+1. At my job, we use GYP generating ninja build files. (I believe GYP can also generate make and CMake files, but using just one build system is so much more convenient.)
GYP is the meta-build system that Google devised for building Chrome on multiple platforms. It works by generating project files and build recipes for other build systems from a single master source. It can generate makefiles, CMake projects, ninja build files, QtBuilder QBS projects, Visual Studio projects, and more.
A GYP project file is essentially a serialized Python data structure (very similar to JSON in format). GYP defines a schema for that structure with which project authors can describe the targets (buildable items, such as programs and libraries), their dependencies, source files and build options.
A typical gyp file might look approximately like this:
{
'targets': [
{
'target_name': 'libhello',
'type': '<(library)',
'sources': [
'include/hello.h',
'src/hello.cpp',
],
'all_dependent_settings': {
'include_dirs': [
'include',
],
},
},
{
'target_name': 'hello',
'type': 'executable',
'dependencies': [
'libhello',
],
'sources': [
'demo/hello_demo.cpp',
],
},
],
}
If you are interested, you can find more information in the GYP wiki. But it might not be feasible to make a complete GYP project parser as it can have really complicated rules. E.g. one GYP file may define several variables and then include another GYP file.
If you can parse ninja build files, this will help me and at least one of my co-workers tremendously.
@yurikhan I'd like to support ninja, but don't have too much time to do the analysis of the build.ninja
Could u do the algorithm analysis?
Let me do the implementation with lisp coding .
You can use the bundled example project for the case study.
cool, thank you
On Tue, Sep 16, 2014 at 11:19 PM, Yuri Khan [email protected] wrote:
I’ll see what I can do, as time permits.
— Reply to this email directly or view it on GitHub https://github.com/redguardtoo/cpputils-cmake/issues/19#issuecomment-55740517 .
help me, help you.