2

When working on a large project which happens to have multiple build systems, (C, C++) in this case, they may use multiple build systems -- for different platforms, or for historic reasons.

With the popularity of meta-build systems, there is the opportunity to use a single build system which can generate files for different platforms.


The disadvantages for using multiple build-systems seem rather obvious...

  • maintenance overhead.
  • higher barrier of entry for developers,
    (needing some experience in multiple build systems)
  • more files to navigate in the source repository.

Ignoring the effort it may take to do the initial migration, are there any advantages to keeping multiple build-systems in use? (when there is the opportunity to use only one?)

Said differently, if someone comes into a project and suggests to use a single cross platform build system, are there any reasonable arguments against this?


Since it was requested I be more specific, the projects I have in mind are large C/C++ code bases, using a mix of automake, MSVC-project-files, SCons & in one case CMake (which is an example of a meta-build system).

  • It really depends on the project, the target operating system (or bare hardware), the compiler, etc... Your question is too broad and matter of opinion. Consider editing it to explain which kind of large project matters to you – Basile Starynkevitch Apr 4 '15 at 9:51
  • I wanted to keep it general since I didn't think the specific build systems were so important. And wanted to avoid answers favoring specific technologies. But added footnote with some specifics. – ideasman42 Apr 4 '15 at 9:59
  • 1
    "Ignoring the effort it may take to do the initial migration" - what makes you believe that this effort can be ignored? – Doc Brown Apr 4 '15 at 10:57
  • @Doc Brown, I say this because I want to compare the merits of 2 different situations. Without worrying about the details about switching from one to another. In a few examples I can think of the migration is done (in a branch, or the other systems just never got removed, even though they are no longer essential). – ideasman42 Apr 4 '15 at 11:08
2

Your question is still too broad.

Notice that Cmake is explicitly a cross-platform and compiler independent meta-builder.

You are mentionning Windows products, and I don't know and never used Windows, and notice that Unix and POSIX have a little bit standardized building: invocation of cc, standardization of a POSIX make specification.

Notice also that builder systems (even legacy ones) are still making significant progress. In particular GNU make has made very significant process in its 4.x version, with important features like Guile integration which would enable projects to avoid metabuilders. However, most software are not using recent features of GNU make (which I feel could be used even to avoid autoconf etc...)

I feel that the main advantage of Cmake is cross-platform abilities.

Notice also that other build systems (e.g. omake) could probably be used to avoid metabuilder.

| improve this answer | |
2

When changing or reorganizing tools from your development infrastructure, the tradeoffs are almost always the same, if it is the compiler, the IDE, the VCS or the build system:

  • the change will need some effort - with no immediate customer value

  • the team (or parts of it) typically knows the existing tools, but not the new tools. So people have to get training, which takes time and money, with no immediate customer value.

  • when trying to introduce a "one size fits all" solution, you have the risk learning that not every feature which was available in the old tool will be available in the same quality in the new one.

So when changing the build tools, there must be some clear value in it at least for the existing team, not just for new devs, and the value must be enough to convince even your boss that it outweighs the disadvantages above.

In your current situation I suggest you identify if there are parts of current the build process where the team is unsatisfied with. That's the part where you have a chance to remove an old build tool and replace it by a newer, more standardized one.

| improve this answer | |
  • Note, that this this isn't necessarily a change to a new system. It may just be dropping support for build systems which is only there for historic reasons, though your points apply to this case too. – ideasman42 Apr 4 '15 at 11:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.