Build system woes.

[whowhatwhere]

Short and sweet: Linux build systems suck.
Yes, I know about SCons and Cmake and all the other make-clones. Don't even suggest using autohell because that's out of the question.
Specifically, I have a hard time finding a build system that doesn't make assumptions and still provides cross-platform build capabilities.

So my question is:

What's in a build system? How would you like to see one designed?

[JohnnyTheDon]

Whats wrong with scons? It definitely isn't a make clone...

Its 'makefiles' are python scripts so you should be able to do whatever you need to, and it has built-in cross platform capabilities.

However, if you are trying to get cross-platform builds for an OS, you are asking too much of your build system. Scons would probably still be your best choice because you could test for different platforms in python.

[Troy Martin]

I'd like a multi-programming language one, with at least C, C++, and assembly support. Something with a simple syntax as well.

A cross-platform utility for using the scripts would be nice too!

[whowhatwhere]

I'd like a multi-programming language one, with at least C, C++, and assembly support. Something with a simple syntax as well.

A cross-platform utility for using the scripts would be nice too!

define-syntax anyone?
/schemes

[Love4Boobies]

I'd like a multi-programming language one, with at least C, C++, and assembly support. Something with a simple syntax as well.

A cross-platform utility for using the scripts would be nice too!

And what would be the difference between the build system and a program you'd write in C/C++/assembly/whatever compiling the program for you? Besides, a build system is supposed to be simple (assembly???), portable (assembly???) and it's supposed to build (as opposed to giving you the ability to create a Pac-Man game), which is why I can't see any of these suggestions to be fit. The best build system would probably be an automated one that lets you mess around with it - it's the project you're supposed to focus on, not the build system so best let it work for you, not against you.

[pcmattman]

I'd like a multi-programming language one, with at least C, C++, and assembly support.

I agree with Love4Boobies here - the build system should work irrespective of specific toolsets. Therefore all build systems are in practice multi-programming.

[Craze Frog]

Have you tried jam?

[skyking]

I use SCons, it's definitely not a make clone (if you think that you have obviously not tried SCons vs make). It works well in cross platform build scenarios (I use it both for building under linux and windows and it's basically one of the few choices if you want to do this without using cygwin).

First I tried to use make, but since there are some problems (nmake is nowhere near compatible with other makes and it really problematic when it comes to hierarchical builds). Then i tried jam which looked quite promising, but it was hard to make it do what I wanted because I think it wasn't really doing what it was supposed to in all cases. Finally I found SCons and was able to control it in a way that fitted my desires.

And yes your build system has to support your development, but that is not to say that the build system may need to be customized to your needs -- otherwise you're creating a contradiction with the original wish (you can't have a build system that does not do a lot of assumptions and yet impose a lot of assumptions (defined by your needs) on it).

[JamesM]

Hi,

Short and sweet: Linux build systems suck.
Yes, I know about SCons and Cmake and all the other make-clones. Don't even suggest using autohell because that's out of the question.
Specifically, I have a hard time finding a build system that doesn't make assumptions and still provides cross-platform build capabilities.

So my question is:

What's in a build system? How would you like to see one designed?

Please STFW before making such completely foundless assertions - SCons has nothing in common with Make whatsoever - it's a python script, essentially.

CMake is a cross-platform, cross-build-system configure tool - it can generate Unix Makefiles, Visual Studio projects, Code::Blocks projects, you name it. So its not a Make clone at all, it can just generate the makefiles for you. Which has the advantage that it's portable to almost every *nix out there.

Please do your research first. I'd reccommend CMake or SCons, I've used both and each has their own ups/downs.

[Solar]

"X sucks, let's make Y."

My advise: Take your time, a piece of paper or two, and write down exactly why you think "X sucks". Then give your paper to someone who's good at using X, and find out if your disenchantment with X is simply because you haven't understood it yet.

And if the "X person" tells you that you're actually right, then sit down with a different paper or two, and write down how Y could do things better than X, in detail.

Only then you're set for actually designing Y.

That being said, for all my C/C++ requirements (and much more, actually), I haven't found automake / autoconf / make lacking yet. Mind you, I've found many a Makefile or configure.in to be very poorly done, but I wouldn't know how to improve on the tools themselves. Perhaps you know more than me, enlighten me...

[whowhatwhere]

Hi,

[snip]

Please STFW before making such completely foundless assertions - SCons has nothing in common with Make whatsoever - it's a python script, essentially.

CMake is a cross-platform, cross-build-system configure tool - it can generate Unix Makefiles, Visual Studio projects, Code::Blocks projects, you name it. So its not a Make clone at all, it can just generate the makefiles for you. Which has the advantage that it's portable to almost every *nix out there.

Please do your research first. I'd reccommend CMake or SCons, I've used both and each has their own ups/downs.

I have done research.

I have used both SCons and CMake on many of projects outside of osdev, and all have failed do to what was required properly across multiple platforms. Cmake was horrible to set up from a syntax point of view. SCons works great, as long as you aren't trying cross-platform builds on end-user systems. The inheritance policies of 'SConscripts' and such are impossible to manage from a high level. Eventually I just went back to using shell scripting and makefiles to do what was required, which surprisingly was much more intuitive and predicable than that of SCons. Being a maintainer for a lot of projects gives me the right to make assertions about the current state of many build systems, and thus they aren't 'foundless'.

"X sucks, let's make Y."

My advise: Take your time, a piece of paper or two, and write down exactly why you think "X sucks". Then give your paper to someone who's good at using X, and find out if your disenchantment with X is simply because you haven't understood it yet.

And if the "X person" tells you that you're actually right, then sit down with a different paper or two, and write down how Y could do things better than X, in detail.

Only then you're set for actually designing Y.

That being said, for all my C/C++ requirements (and much more, actually), I haven't found automake / autoconf / make lacking yet. Mind you, I've found many a Makefile or configure.in to be very poorly done, but I wouldn't know how to improve on the tools themselves. Perhaps you know more than me, enlighten me...

I didn't say "let's make Y". That was your assumption.
I said: "What's in a build system? How would you like to see one designed?".
I agree with you about poorly made autoconf systems within projects. Being a maintainer, I've encountered far too many of them to be happy with the state they've become. The plague every project I've seen by demanding specific versions of the build system and usually install things in places that break the Makefile they generate, or other such things. Not only that, but when downloaded for instance from a remote repository, they modify the folder from which they were saved to, and thus even after a 'make distclean' three quarters of the remaining files are still left over. Yes, this can be mitigated by making a brand new 'build' folder and running the configure script from there, but then again, sometimes that doesn't even work, and other times the creator of the package has specifically broken the build system by requiring the user to be in the original source directory when configuring the package, invalidating the only relatively sane method of not polluting the build environment with useless files. Don't even get me started about "config.h" files.

The reason I made this thread was because I wanted to brainstorm with other competent developers to find ideas for a minimalistic and simple build system that does NOT pollute the source directory, and still allows flexibility and portability without such a heavy infrastructure like autohell, without premade assumptions about how the linking system works, and with a sane and legible syntax for configuration, in a single file.

[Solar]

There's no way to make stupid people write smart configuration files for their projects.

Today most people (in the userspace world, which is where 99% of the work is being done) use whatever their IDE comes with. And adding to the trouble, many languages come with their own build systems, further fragmenting the problem domain.

Regarding make, autoconf et al., I consider them "good enough" tools, with a frightfully bad approach to documentation.

[JackScott]

What documentation? Is there a new package I should have apt-got?