• Advertisement
Sign in to follow this  

The Current State of Build Systems

This topic is 3841 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

All of the current build systems are lacking in a lot of ways. It's a sad fact. The following is an outline of what I believe makes for a good build system.
  • Cross platform
    • The same build script should be able to build on all platforms without any modifications
    • Each platform's implementation will be modified to facilitate this, the implementation knows where things are located, what things are available, and what proper substitutes exist if any
  • Modular build list construction
    • There should be more than one way to tell the build system what to do
    • Python construction
      • One method of construction should be short, concise and expressive, a python based method would be appropriate
    • XML construction
      • The other method should be universally legible by applications, XML is exactly that.
      • Unlike other XML based systems, however, this should also be as short, concise, and as expressive as possible, so that hand editing of XML files is possible.
    • File globbing
      • Files should be accessible as groups as well as individual files.
  • Globbing
    • Specifying *.cpp would collect all of the cpp files in the current directory.
  • Regex
    • Regular expressions will be available to seek out files
  • Modular build process
    • Support multiple languages
      • C
      • C++
      • Java
      • C#
    • Support cross compiling
  • Variant builds
    • Debug
    • Release
  • No configuration
    • Build list construction often is plagued by conditionals
      • These obfuscate the build list
      • They complicate the build list
      • ‣ They reduce time spent on the program itself
  • Fast Incremental Builds
    • Daemon mode
      • The program could stay resident and accept commands from the "client" program
    • Pickle classes in between running
  • Should not clutter development directory with intermediate files
Now, there are plenty of build systems out there and each should be considered. Autotools - This is the oldest and the ugliest of the build systems. It requires multiple input files, and often one in each subdirectory. Autoconf files are written in the arcane M4 macro language, a language few bother to learn except to write autoconf files. A build system should not force the programmer to learn an entirely new language, if the build listing insists on being a script, it should be a well known language. Autoconf files have the added complexity of requiring extensive configuration and checks. This is a product of the times, the fact of the matter is, nowadays POSIX compliant systems all provide a sane or semi-sane build environment, which can be taken for granted. Automake files require the tedious listing of each individual source file, resulting in long lines or excessive line breaks, not to mention the monotony of cracking open the file and adding yet another source file to the list every time a new file is added. Then there's the fact that autotools is more than one tool, it's an entire toolchain, each of which must be invoked separately and in the correct order to build a project, the fact that most every project inevitably creates its own autogen.sh is a testament to this sad fact. Last, but not least, autotools mucks up your development tree with tons of intermediate files, and at the end of the day the product is a simple makefile. (And of course there's the issue of recursive make) SCons - SCons gets a lot right, it uses a well known scripting language, doesn't clutter the development environment with intermediate files (at least not SCons intermediate files, object files are ok) and simple SConstruct files can be made relatively quickly. Now for the bad, the worst thing about SCons is the amount of documentation browsing required to compile a simple c++ program with a few library dependencies. Add to that the fact that half of the functions in the documentation are, well, undocumented, and you have a recipe for a lot of hair pulling. Another annoyance is the fact that you must list source files individually, the way around this of course is importing the glob module and using it, but that sort of functionality should already be included. In the end SCons isn't a terrible build system, but there are a lot of places it needs work, especially in the API provided. CMake - Next to autotools this is my least favorite of the bunch, I have plenty of gripes with it, though admittedly i never delved too deep into it. This is another makefile generator, and like all makefile generators it is limited by the capabilities of make, including the aforementioned recursive make problem. CMake makes many things easy, but most example files are heavy on conditionals and configuration. Including libraries is also non-trivial, it involves including multiple CMake files such as FindOpenGL.cmake and using the libraries after that, to add to the confusion these modules aren't uniformly named and aren't available for all libraries one might need. CMake also uses its own scripting language which isn't horrible, however, it isn't well known outside of the cmake community. Waf - I was excited about waf when I first heard about it and saw how it worked, however my soaring expectations were quickly shot down when I finally used it. I'll start with the good, because there was a lot of it. First, the script files were in python, a big bonus, many people dabble in python and would know enough to get by in waf. The second good thing was the scripts were well organized, they were divided into different functions which had different tasks. It supports variant builds and the icing on the cake was, it supported an XML format. Now for the bad, first of all it's immature and it shows. It was hard to tell what was a bug and what was intended behavior. It was totally unintuitive for me, I always want to write one script in the project directory and be done with it, but waf didn't function correctly unless I put one in the source dir that did all the work, and the script in the project directory had to explicitly delegate work to the script in the source directory. Then there was the uselib system, which seemed rather roundabout and cumbersome, far more work than I feel is necessary. As for the XML format, it was a mess, little more than a python script formatted like XML, hardly the short, concise build list I was hoping it would be. Note: I know I have left out a few build systems including plain old make, Ant, NAnt and a few others, however I don't have enough experience with the Ants to speak about them, and make's shortcommings are well known. Having expressed my displeasure with all of the current build systems it's now time for me to transform from a whiner into someone who will do something about it, I've been working for a time on my project which I call "yams" which stands for yet another make system. My project aims to fulfill all of the goals mentioned above, and possibly more in the future, it currently does nothing, but I hope to work on my system this summer and turn it into something worthy of attention and praise. So what do you guys think about my criteria and my analysis of the existing build systems? I'm not looking to start any flame wars or anything but I really feel there is a large void for a good (and easy to use) cross platform build system. And my apologies if my writing was poor or even my formatting was poor. cheers -Dan P.S. My html list may be a bit mucked up, I built it sort of hastily and I don't think all of the tags match up correctly. EDIT: made my introductory statement a little less inflammatory, and improved my grammar, I must be tired.

Share this post


Link to post
Share on other sites
Advertisement
I think your main unspoken requirement is that your tools should follow the paradigm that became popular with the Microsoft Windows operating system (that is, one program that hides the nasty bits from the user under a facade) rather than one that follows the Unix paradigm of one tool to do one thing and the ability to chain modules together to form a sum greater than the parts.

That's fine, but you should make your assumption explicit.

Now, I've dealt with a large cross-section of build tools in my time, and I would divide them into two main groups: those that need to be ported to new environments, and those that don't. It's my experience that the first group consists of the autotools, and everything else belongs in the second group. You might think that's no big thing, since you're only ever going to target, say, Mac OS X 10.3 or Fedora Core 5. Except that one day you absentmindedly click on the "install all updates" button and find you can't build you apps any more because bjam hasn't been ported to GCC 4.4 yet.

As for your other criticisms of the autotools: yes, you have to learn how to write scripts in the various autotools languages to use those tools. This same criticism applies to each and every one of the tools you mentioned and is not unique to autotools. It's also not true that all posix environments are the same: I use the autotools every day to build Linux software targeted for Debian (etch and sarge) and Red Hat (4 and 5) on both 32- and 64-bit architectures and each of those 8 target platforms is different despite all of them being LSB-compliant Linux distros. Now add in additional POSIX-compliant systems like cygwin, OS X, Solaris, and so on and watch the cross-platform problem multiply.

Oh, and the autotools only leaves dreck in your source directory if you're foolish enough to actually build in your source directory. How well do the other tools fare when asked to build from source mounted on a readonly share?

--smw

Share this post


Link to post
Share on other sites
I recommend you consider a different name, since YAMS appears to be taken:
http://yams.sourceforge.net/

It doesn't appear to be active, but it's still not nice to hijack a project name. The "yet another" projects are also very common, and may result in confusion with other "yet another" projects (such as "YAM" or "YAML").

Share this post


Link to post
Share on other sites
I currently use SCons, which manages to do most things I need.

Minor problems arise with libraries and building outside the source directory.

A more serious problem that doesn't effect me is that SCons has limited knowledge of the compiler's features; you can't, for example, portably specify optimization settings.

Cross platform build systems are possible, but only for cross platform programs. If you have a program which includes source files for both GLX and GDI, it's not reasonable to expect the build system to magically tell that you want to use the GLX file on a POSIX system and GDI on a Windows system.

I'm toying around with a homebrew build system in Lisp (but not just for building Lisp programs) similar in style to SCons and ASDF.

Share this post


Link to post
Share on other sites
I currently use premake and it would take something special for me to change my build tool, it does everything which I require using Lua which I am very comfortable with.
http://premake.sourceforge.net/

Share this post


Link to post
Share on other sites
Quote:

I think your main unspoken requirement is that your tools should follow the paradigm that became popular with the Microsoft Windows operating system (that is, one program that hides the nasty bits from the user under a facade) rather than one that follows the Unix paradigm of one tool to do one thing and the ability to chain modules together to form a sum greater than the parts.

That's fine, but you should make your assumption explicit.

Now, I've dealt with a large cross-section of build tools in my time, and I would divide them into two main groups: those that need to be ported to new environments, and those that don't. It's my experience that the first group consists of the autotools, and everything else belongs in the second group. You might think that's no big thing, since you're only ever going to target, say, Mac OS X 10.3 or Fedora Core 5. Except that one day you absentmindedly click on the "install all updates" button and find you can't build you apps any more because bjam hasn't been ported to GCC 4.4 yet.

As for your other criticisms of the autotools: yes, you have to learn how to write scripts in the various autotools languages to use those tools. This same criticism applies to each and every one of the tools you mentioned and is not unique to autotools. It's also not true that all posix environments are the same: I use the autotools every day to build Linux software targeted for Debian (etch and sarge) and Red Hat (4 and 5) on both 32- and 64-bit architectures and each of those 8 target platforms is different despite all of them being LSB-compliant Linux distros. Now add in additional POSIX-compliant systems like cygwin, OS X, Solaris, and so on and watch the cross-platform problem multiply.

Oh, and the autotools only leaves dreck in your source directory if you're foolish enough to actually build in your source directory. How well do the other tools fare when asked to build from source mounted on a readonly share?

--smw


Well thank you I really do appreciate the critique (as i really was asking for a critique). I never really thought of it as the "windows way" but did read this and it clicked with me. As far as building from source on a readonly share, that feels more like a feature gained through maturity, not necessarily a testament to its good design (but maybe thats what you were saying anyways, I don't know).

As far as POSIX compliance goes, you say that all POSIX compliant operating systems aren't the same, which is obviously true, but from a build system's stand point are there any really SIGNIFICANT differences?

Obviously the file system hierarchy might be slightly, or even wildly different, however that's easily handled within a build systems implementation. Also, don't all POSIX systems more or less comply with the filesystem hierarchy standards? (I get the impression that you're already familiar with this document but it doesn't hurt to link to it Filesystem Hierarchy Standards)

Are there any other considerable differences?
I suppose the available libraries might differ, though I expect that wouldn't stop the build from succeeding in most cases.

Those are really the only two significant differences I can think of and one is easily remedied, and as far as available libraries goes, a system can and should have a way to test for library versions, and have a uniform way of informing the code.

Finally there was that issue of "having to be ported" and I think you're right, but that sort of case can be handled *i think*. Take gcc like you were saying, unless the command to correctly call gcc has changed between releases (i haven't been in the unix world long enough to know if that's common) things should still hold together.

Quote:

I recommend you consider a different name, since YAMS appears to be taken:
http://yams.sourceforge.net/

It doesn't appear to be active, but it's still not nice to hijack a project name. The "yet another" projects are also very common, and may result in confusion with other "yet another" projects (such as "YAM" or "YAML").


Thanks for the heads up somehow I missed that, maybe I'll come up with a better name then.

cheers
-Dan

Share this post


Link to post
Share on other sites
Without (n)Ant, arguably the most common cross-platform build system after Autotools, your list is incomplete, and your proposed solution (roll your own) is not yet a well-founded one. The internet is littered with half-baked open-source projects which never became popular because they didn't differentiate themselves from the top quality alternatives. (CMake's one of them.)

Oh, and when evaluating Ant, beware of The Blub Paradox, and confirmation bias in general. Once one is excited about a new project, it becomes difficult to objectively measure its merits.

Share this post


Link to post
Share on other sites
Well, I did acknowledge that I haven't used NAnt or Ant enough for me to be qualified to critique them. But my understanding was that NAnt lacked c/c++ support and what I saw of both system's build scripts still felt overly verbose. Maybe I'm too picky, or whatever, I don't know. I understand your point about creating yet another half complete build system though. But I guess a major motivation for me posting about it here was to avoid exactly what you were saying, not being able to objectively see whether or not my project is actually needed, and whether or not it was in fact a worthwhile project.

cheers
-Dan

EDIT: Though I'm still rather certain I want to continue with my project at this point I really do want feedback on whether the goals I have in mind for it are really worth while and really desired by more than just myself, who knows maybe I'm just crazy (i'm not... right?... :-( ).

Share this post


Link to post
Share on other sites
Quote:
Original post by Ademan555
But my understanding was that NAnt lacked c/c++ support
What? No. What led you to believe this?
Quote:
what I saw of both system's build scripts still felt overly verbose.

Only inasmuch as XML is a verbose format. I've never heard complaints about this aspect of Ant.
Quote:
Maybe I'm too picky, or whatever, I don't know.

Dismissiveness is the easiest way to not have to learn something.

Share this post


Link to post
Share on other sites
Quote:
Original post by Ademan555... my understanding was that NAnt lacked c/c++ support...

ANT has pretty good C++ support through an add-on package. The downside is that, like Eclipse, ANT is built around a Java round hole and a C++ square peg doesn't always sit right.
Quote:
Though I'm still rather certain I want to continue with my project at this point I really do want feedback on whether the goals I have in mind for it are really worth while and really desired by more than just myself, who knows maybe I'm just crazy (i'm not... right?... :-( ).


Delusional yes, Crazy, no.

Seriously, don't give up. Did Linus Torvalds give up developing his operating system just because DR-DOS was available and used by professionals everywhere? (cue Elgar) Did the Carthaginians give up inventing English just because the Romans defeated them utterly in the third Punic war -- no! they went on to settle in Norway and gave birth to the greatest empire ever to exploit the unwashed masses!

Seriously, if your system works better, it will be adopted. Just make it work better.

--smw

Share this post


Link to post
Share on other sites
Quote:
Original post by Bregma
Quote:
Though I'm still rather certain I want to continue with my project at this point I really do want feedback on whether the goals I have in mind for it are really worth while and really desired by more than just myself, who knows maybe I'm just crazy (i'm not... right?... :-( ).

...
If your system works better, it will be adopted.

Or, more likely, it won't. Maybe it'll only be better for the projects you want to make.

Worrying about whether other people will want to use your build system is silly. If your build system only enables you to program more effectively, it will already have been successful.

Share this post


Link to post
Share on other sites
We used NANT as the backbone of our automated build system at my previous employer. Primarily, we were a C# shop, but our code-bases often contained other files such as XML, javascript or data files.

I always found NANT to be easy to work with. Its XML files are easy to generate from other applications -- Since we were basically software-for-hire, we created new codebases several times a week, we created a simple tool to add new projects to our build system, which itself was integrated into our customer management system: When the bid became a contract, our source repository was created and configured for nightly builds. I think that's one thing you haven't explicitly stated as a goal (though perhaps it goes without saying) -- A good build tool is easily integrated into larger, possibly pre-existing build environments. Nant's configuration files were quite intuitive, and even adding support for non-supported tools was easy.

Share this post


Link to post
Share on other sites
Here is my feedback/question about your plan: You state that you will allow "No configuration" but also state that you will "Support cross compiling". Can you expand on your "no configuration" plan a little? How you can allow cross-compilation if the user can't configure some options somewhere (at least which platform to compile for)? Perhaps I am misunderstanding what you mean by "no configuration", though.

Remember that what makes a "good" build system for you, may make a frustrating and restrictive build system for me. Ultimately, I'd say it boils down to whether or not the existing alternatives are bad enough to justify spending time developing a whole new build system. You say build configuration takes time away from development, is it worth the time lost on whatever project(s) you are working on to implement your own build system? For me, CMake works well enough. It's not perfect, but it works. Now that I got it set up I can deal with the project itself.

Like others, I'd say just because all of us are not ready to abandon our current build systems at the first mention of a new system, that doesn't mean you shouldn't spend some time on this. I'd encourage you to think all this through carefully though and make sure it's really worth the time it will take.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by Ademan555
But my understanding was that NAnt lacked c/c++ support
What? No. What led you to believe this?

Well can you link me to anything talking about NAnt c++ support? I couldn't find anything. I found a blog entry that talked about c++ support but went on to just load a visual studio solution file.

Quote:
what I saw of both system's build scripts still felt overly verbose.

Only inasmuch as XML is a verbose format. I've never heard complaints about this aspect of Ant.[/quote]

I guess my complaint is less about verbosity and more about the way it works, ant to me feel more like a scripting language with xml tags rather than a declaration of what needs to be built and how.

Quote:
Quote:
Maybe I'm too picky, or whatever, I don't know.

Dismissiveness is the easiest way to not have to learn something.

Huh? What am I avoiding learning? Ant and/or NAnt? I still remain unconvinced that NAnt has real c++ support, and even if there is support it is entirely undocumented, because I distinctly remember searching for documentation on it. As for Ant, my resistance to that is solely based on my above complaints.

EDIT: Sneftel: If what you're trying to say is that I should really learn Ant and/or NAnt before I pass judgement on them and decide they're incapable, that is a good point, I'm seriously going to check out Ant right after I take a shower. As for NAnt I'll try that if I find any decent information about c++ support.

Quote:
Original post by Bregma
Quote:
Original post by Ademan555... my understanding was that NAnt lacked c/c++ support...

ANT has pretty good C++ support through an add-on package. The downside is that, like Eclipse, ANT is built around a Java round hole and a C++ square peg doesn't always sit right.
Quote:
Though I'm still rather certain I want to continue with my project at this point I really do want feedback on whether the goals I have in mind for it are really worth while and really desired by more than just myself, who knows maybe I'm just crazy (i'm not... right?... :-( ).


Delusional yes, Crazy, no.

Seriously, don't give up. Did Linus Torvalds give up developing his operating system just because DR-DOS was available and used by professionals everywhere? (cue Elgar) Did the Carthaginians give up inventing English just because the Romans defeated them utterly in the third Punic war -- no! they went on to settle in Norway and gave birth to the greatest empire ever to exploit the unwashed masses!

Seriously, if your system works better, it will be adopted. Just make it work better.

--smw

Thanks for the advice, I'm pretty sure I will continue with this, but I also believe Sneftel had a good point(provided I understood him correctly) when he said that I should try the rest of the tools more in depth before I decide that all of the current build systems suck.

Quote:
Original post by Nathan Baum
Quote:
Original post by Bregma
Quote:
Though I'm still rather certain I want to continue with my project at this point I really do want feedback on whether the goals I have in mind for it are really worth while and really desired by more than just myself, who knows maybe I'm just crazy (i'm not... right?... :-( ).

...
If your system works better, it will be adopted.

Or, more likely, it won't. Maybe it'll only be better for the projects you want to make.

Worrying about whether other people will want to use your build system is silly. If your build system only enables you to program more effectively, it will already have been successful.

That is an interesting point, making myself more productive is obviously my ultimate goal, but I do have the desire to boost the community as well which is why i've been fishing for feedback.

Quote:
Original post by ravyne2001
We used NANT as the backbone of our automated build system at my previous employer. Primarily, we were a C# shop, but our code-bases often contained other files such as XML, javascript or data files.

I always found NANT to be easy to work with. Its XML files are easy to generate from other applications -- Since we were basically software-for-hire, we created new codebases several times a week, we created a simple tool to add new projects to our build system, which itself was integrated into our customer management system: When the bid became a contract, our source repository was created and configured for nightly builds. I think that's one thing you haven't explicitly stated as a goal (though perhaps it goes without saying) -- A good build tool is easily integrated into larger, possibly pre-existing build environments. Nant's configuration files were quite intuitive, and even adding support for non-supported tools was easy.

Well, so long as NAnt does have c++ support it does sound attractive, thanks.

Quote:

Here is my feedback/question about your plan: You state that you will allow "No configuration" but also state that you will "Support cross compiling". Can you expand on your "no configuration" plan a little? How you can allow cross-compilation if the user can't configure some options somewhere (at least which platform to compile for)? Perhaps I am misunderstanding what you mean by "no configuration", though.

I think we're misunderstanding each other too, although I could even be using no-configuration incorrectly. What I meant by configuration was the often long and tedious set of checks and conditions found in autotools files. Doing certain things if Glib version X isn't available, doing others if Glib version Y IS available, and so on.

Quote:

Remember that what makes a "good" build system for you, may make a frustrating and restrictive build system for me. Ultimately, I'd say it boils down to whether or not the existing alternatives are bad enough to justify spending time developing a whole new build system. You say build configuration takes time away from development, is it worth the time lost on whatever project(s) you are working on to implement your own build system? For me, CMake works well enough. It's not perfect, but it works. Now that I got it set up I can deal with the project itself.

Like others, I'd say just because all of us are not ready to abandon our current build systems at the first mention of a new system, that doesn't mean you shouldn't spend some time on this. I'd encourage you to think all this through carefully though and make sure it's really worth the time it will take.

Thanks, and I do agree that my checklist for an ideal build system may be different from other peoples, and that's a large part of why I posted here, to see if people cared, and to see if my needs were largely in line with other people's needs.

cheers
-Dan

And again, thank you all for your responses I'm really glad to be discussing this with people.[/quote]

Share this post


Link to post
Share on other sites
Quote:
Original post by Ademan555
I still remain unconvinced that NAnt has real c++ support, and even if there is support it is entirely undocumented, because I distinctly remember searching for documentation on it.

Clicky. This was the first result when I googled for "nant c++ task".

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by Ademan555
I still remain unconvinced that NAnt has real c++ support, and even if there is support it is entirely undocumented, because I distinctly remember searching for documentation on it.

Clicky. This was the first result when I googled for "nant c++ task".


Geeze, well you're certainly right, that's embarassing. Either way thanks.

EDIT: while you're certainly right, the page specifically notes
Quote:

Compiles C/C++ programs using cl.exe, Microsoft's C/C++ compiler.

This task is intended for version 13.00.9466 of cl.exe.


cheers
-Dan

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement