3 ms·

CMake is doing more than generating a build file, it's also a configuration tool (detecting compiler, finding dependencies, etc).

by Orphis 8y ago

enriquto 8y ago
The dependences do not change upon distribution, so they can be safely encoded on the makefile. As for "detecting" the compiler, either it is in the path, or in the CC variable (or analogous), in which case the makefile can work; I do not honestly understand what is the task of cmake here. The only use that I can see is creating projects for other build-systems, e.g. for windows. But if you only distribute your code to posix systems, and your project is small(ish), then cmake does not really add anything.
- rcxdude 8y ago
  The dependencies do change depending on the user. Different version of libraries will be in different locations, may require different build flags, etc, etc. Likewise the build may support a range of compilers which require (sometimes completely) different compiler options for a successful build. This is the reason autotools existed in the first place (and it was only intended to even out the differences between 'POSIX' systems in the first place). In general though, if you're just talking about small projects, I have found the easiest way to incorporate smaller librares into a build system is to just ignore whatever build system they are using and re-write the build in the larger build system (even if they are the same tool!). This is mostly because the current state of build systems is so terrible.
  - enriquto 8y ago
    > The dependencies do change depending on the user. Different version of libraries will be in different locations, may require different build flags, etc, etc. Likewise the build may support a range of compilers which require (sometimes completely) different compiler options for a successful build. What you say is true, but it can be interpreted as either positive or negative features. I would say that code that depends on specific versions of a library or specific compiler options is bad code; and propagating bad code instead of fixing it is not a good idea. Cmake makes it very easy and convenient to ship bad code, as you explain. Thus, it is a force of evil! It allows, even encourages, the programmers to be sloppy without short-term visible consequences.
    - rcxdude 7y ago
      I'm talking about trying to make a shared library versus a static library vs an executable, or include different directories. I'm not talking about depending on '-O2' for correctness. Likewise with different versions of a library in different locations. And even in the case of more obscure flags, the cause is usually bad or incompatible compilers or libraries, not 'bad code' on the part of the project. A build system needs to be able to deal with a large variety of situations, because ultimately the responsibility for making the project build is on the project and the build system, not the user and their environment.

CMake is doing more than generating a build file, it's also a configuration tool (detecting compiler, finding dependencies, etc).

by Orphis 8y ago

CMake is doing more than generating a build file, it's also a configuration tool (detecting compiler, finding dependencies, etc).

enriquto 8y ago

The dependences do not change upon distribution, so they can be safely encoded on the makefile. As for "detecting" the compiler, either it is in the path, or in the CC variable (or analogous), in which case the makefile can work; I do not honestly understand what is the task of cmake here. The only use that I can see is creating projects for other build-systems, e.g. for windows. But if you only distribute your code to posix systems, and your project is small(ish), then cmake does not really add anything.

rcxdude 8y ago
The dependencies do change depending on the user. Different version of libraries will be in different locations, may require different build flags, etc, etc. Likewise the build may support a range of compilers which require (sometimes completely) different compiler options for a successful build. This is the reason autotools existed in the first place (and it was only intended to even out the differences between 'POSIX' systems in the first place). In general though, if you're just talking about small projects, I have found the easiest way to incorporate smaller librares into a build system is to just ignore whatever build system they are using and re-write the build in the larger build system (even if they are the same tool!). This is mostly because the current state of build systems is so terrible.
- enriquto 8y ago
  > The dependencies do change depending on the user. Different version of libraries will be in different locations, may require different build flags, etc, etc. Likewise the build may support a range of compilers which require (sometimes completely) different compiler options for a successful build. What you say is true, but it can be interpreted as either positive or negative features. I would say that code that depends on specific versions of a library or specific compiler options is bad code; and propagating bad code instead of fixing it is not a good idea. Cmake makes it very easy and convenient to ship bad code, as you explain. Thus, it is a force of evil! It allows, even encourages, the programmers to be sloppy without short-term visible consequences.
  - rcxdude 7y ago
    I'm talking about trying to make a shared library versus a static library vs an executable, or include different directories. I'm not talking about depending on '-O2' for correctness. Likewise with different versions of a library in different locations. And even in the case of more obscure flags, the cause is usually bad or incompatible compilers or libraries, not 'bad code' on the part of the project. A build system needs to be able to deal with a large variety of situations, because ultimately the responsibility for making the project build is on the project and the build system, not the user and their environment.