7 ms·

Would be nice if you could give an example, not just "use that".

• onli 10y ago
  Especially since scons and cmake are in no way easy to learn, imho.
  • realharo 10y ago
    Still hell of a lot simpler than hand-writing Makefiles though. For both small and large projects. I mean, a "hello world" CMakeLists.txt can be literally just this: add_executable(hello hello.c) And it's cross-platform, can generate Visual Studio/Xcode/... projects, etc.
    • onli 10y ago
      I think we have to go deeper than that to really see an advantage of cmake. A corresponding makefile would be: all: hello That's not really complicated either.
      • radarsat1 10y ago
        Exactly. When evaluating a language / build system / whatever, it is definitely not sufficient to look at Hello World. You have to evaluate the worst case and average case if you want to get an idea of what you're in for. Looking at the "best case" (simple one-file project) tells you almost nothing except how hard it is to get started.
        • ryandrake 10y ago
          When evaluating build systems, one of my major questions is: How much "magic" will I have to work-around in order to do something off the beaten path that the build system's developers never considered? This is a good criteria for languages as well.
      • stormbrew 10y ago
        The thing is that these are not equivalent hello worlds. I mean, if only for the fact that the cmake example does proper header dependency management, which is essential to correctly compiling c/c++ code as it changes. It's not something you can leave out of a makefile and still call it correct.
  • Davidbrcz 10y ago
    Still easier than make...
    • ratboy666 10y ago
      hello.c in a directory make hello Easier?
  • aldanor 10y ago
    cmake is arguably easier to learn than make
    • thymelord 10y ago
      and I argue with your conclusion.
  • grumbel 10y ago
    `scons` is very easy to start with: Program("main", ["main.cpp"]) The problems start once you want configure stages, build directories, portability and install targets, as all of those aspects are extremely lackluster and incomplete in `scons` and you have to reinvent large parts of the build system yourself essentially for anything even mildly complex. `cmake` is much better. The language itself is ugly and takes some getting used to, so it's a little more complicated to get started with then `scons`. `cmake` generating `Makefile`s instead of actually building the project itself also adds a layer of complexity. But once you understand the basics it's much easier to get a fully functioning build going, including configure stages, build directories, portability and all that, as cmake has all of that integrated and working right out of the box. `cmake` feels like a complete build system, while `scons` feels like a good start for a build system that was abandoned at the halfway point. I still use plain `make` for some Python projects (mostly .PHONY targets to run `pylint`, `autopep` and friends), but for everything that needs to get compiled `cmake` is much easier to use than plain `make`, as you don't need to reinvent a build system yourself, it already comes with almost everything you need.
• dilly_li 10y ago
  https://cmake.org/examples/ https://cmake.org/examples/
• Davidbrcz 10y ago
  $ ls src demo.cxx demo_b.cxx CMakeLists.txt $ cat src/CMakeLists.txt cmake_minimum_required (VERSION 2.8.11) project (HELLO) add_executable (helloDemo demo.cxx demo_b.cxx) $ mkdir bin $ cd bin $ cmake ../src SNIP $ make $ ./helloDemo
• Shorel 10y ago
  I would not be using cmake if this repository did not exist: https://github.com/Akagi201/learning-cmake https://github.com/Akagi201/learning-cmake
• joseflavio 10y ago
  # SConstruct file env = Environment() hello = Program(["hello.c"]) $ scons