4 ms·

Now we have N+1 incompatibile build systems.

mhh__ 8y ago
Until you eventually you have n-k fit for purpose build systems. Having competing standards isn't always a bad thing e.g. if they do slightly different jobs
- seanballais 8y ago
  What does k mean?
  - cyphar 8y ago
    Presumably it's the number which are not fit-for-purpose.
  - mhh__ 8y ago
    A number such that n-k is less than n+1
waruqi 8y ago
If the existing tools are really good enough to meet all user needs, there will be no N+1 build systems.
flukus 8y ago
I think half those N's are cmake itself considering the amount of time I see "requires cmake x.x or above" messages. I wouldn't find having many build system such an issue if they'd just add a makefile (and maybe ./configure) to call that build system, giving devs a consistent interface and not having to lookup up how to do a simple build.
- geezerjay 8y ago
  > if they'd just add a makefile (and maybe ./configure) That's the whole point of cmake. Instead of running autotool's ./configure (which in fact is a whole dance involving autoconf, autoreconf, automake, and whatnot) just run cmake . to get yourself a fancy makefile.
  - enriquto 8y ago
    if cmake was any good, the makefiles it produces would be portable, and distributing the cmake program itself would be unnecessary
    - 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
geezerjay 8y ago
> Now we have N+1 incompatibile build systems. To be fair, cmake was at a time the n+1 build system but nowadays it's pretty much the only option in C/C++ land.

Until you eventually you have n-k fit for purpose build systems. Having competing standards isn't always a bad thing e.g. if they do slightly different jobs

seanballais 8y ago
What does k mean?
- cyphar 8y ago
  Presumably it's the number which are not fit-for-purpose.
- mhh__ 8y ago
  A number such that n-k is less than n+1

waruqi 8y ago

If the existing tools are really good enough to meet all user needs, there will be no N+1 build systems.

flukus 8y ago

I think half those N's are cmake itself considering the amount of time I see "requires cmake x.x or above" messages. I wouldn't find having many build system such an issue if they'd just add a makefile (and maybe ./configure) to call that build system, giving devs a consistent interface and not having to lookup up how to do a simple build.

geezerjay 8y ago
> if they'd just add a makefile (and maybe ./configure) That's the whole point of cmake. Instead of running autotool's ./configure (which in fact is a whole dance involving autoconf, autoreconf, automake, and whatnot) just run cmake . to get yourself a fancy makefile.
- enriquto 8y ago
  if cmake was any good, the makefiles it produces would be portable, and distributing the cmake program itself would be unnecessary
  - 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

geezerjay 8y ago

> Now we have N+1 incompatibile build systems. To be fair, cmake was at a time the n+1 build system but nowadays it's pretty much the only option in C/C++ land.