I was just reading Jan's post about how to write a good build system
While I'm not about to write a build system in lua - or anything else, I thought I'd pitch in my thoughts as I've been having a similar problem recently. The problem is, autotools is the only system that doesn't require some prereq to be installed on the system ... other than a working build system. The only real downside to autotools (other than needing to learn m4) is that it is useless on Windows.
As Jan says, though, the other systems fall down on the make dist part. This is way important to me, as I also work in my tree alot and I really want to have an automated step to make sure I'm packaging up all the files I need, but not too many. This leads Jan to the inevitable choice of building his own
First problem - if the user doesn't have the build system, and if autotools won't cut it, then how are they going to build the lua-src.
I'd like to point out that most of this is because Windows is crap. The autotools design goal of not requiring user to install a special build system other than Make is a great one. But because Windows can't even manage to ship a decent POSIX environment, this is broken. Ever tried sharing source with someone who's using VisualStudio? Ever get pissed off because there's no way to have the source figure out where a library dependency is without setting some property in the source by hand?
Anyway - I do think Jan is on to something (as usual) but I don't think the whole system needs to be rewritten - just autoconf.
Automake runs on the maintainer's machine, as does autoconf, but the automake output are the Makefile.in files that autoconf replaces stuff in. There's nothing really broken about this. make, make dist, make distcheck should all still work (ok, except on Windows where they don't have tar... my sympathy is low) But if you made a program in lua that created something like a configure script that could be run with minimal install requirements on the client (I think needing lua is ok here - as Jan says, it's easy to install)
That leaves the requirement of producing MSI targets. I think this is a requirement that should be shucked, because it's not an apples/apples thing. MSI files are the same as RPMs or DEBs. They are packaging, not part of the build, and I think if emitting them is part of the needs, then the build system also needs to be able to make debs. Divorce the work of making MSI files from the build and I think the task is really doable in the short term.
I think that the m4 stuff in autoconf is the only part of autotools that people really get annoyed with. So kill it. Replace it with lua. Or python. Or anything that's cross platform and low impact. (and by that I do not mean Java - sorry guys, the nightmare that is installing Java environments is a subject of an upcoming rant)
I'm in the need for a portable, fast build-system.
While I'm not about to write a build system in lua - or anything else, I thought I'd pitch in my thoughts as I've been having a similar problem recently. The problem is, autotools is the only system that doesn't require some prereq to be installed on the system ... other than a working build system. The only real downside to autotools (other than needing to learn m4) is that it is useless on Windows.
As Jan says, though, the other systems fall down on the make dist part. This is way important to me, as I also work in my tree alot and I really want to have an automated step to make sure I'm packaging up all the files I need, but not too many. This leads Jan to the inevitable choice of building his own
As a matter of fact here I stand without build-system that meets my needs. My current target is building the MySQL Proxy on Linux, MacOS X and win32.
Throwing lua into the game as a nice side-effect: the scripting language is clean and simple. You can also think about adding the lua-src itself to the build-system to do a full bootstrap in case the user doesn't have it install
First problem - if the user doesn't have the build system, and if autotools won't cut it, then how are they going to build the lua-src.
I'd like to point out that most of this is because Windows is crap. The autotools design goal of not requiring user to install a special build system other than Make is a great one. But because Windows can't even manage to ship a decent POSIX environment, this is broken. Ever tried sharing source with someone who's using VisualStudio? Ever get pissed off because there's no way to have the source figure out where a library dependency is without setting some property in the source by hand?
Anyway - I do think Jan is on to something (as usual) but I don't think the whole system needs to be rewritten - just autoconf.
Automake runs on the maintainer's machine, as does autoconf, but the automake output are the Makefile.in files that autoconf replaces stuff in. There's nothing really broken about this. make, make dist, make distcheck should all still work (ok, except on Windows where they don't have tar... my sympathy is low) But if you made a program in lua that created something like a configure script that could be run with minimal install requirements on the client (I think needing lua is ok here - as Jan says, it's easy to install)
That leaves the requirement of producing MSI targets. I think this is a requirement that should be shucked, because it's not an apples/apples thing. MSI files are the same as RPMs or DEBs. They are packaging, not part of the build, and I think if emitting them is part of the needs, then the build system also needs to be able to make debs. Divorce the work of making MSI files from the build and I think the task is really doable in the short term.
I think that the m4 stuff in autoconf is the only part of autotools that people really get annoyed with. So kill it. Replace it with lua. Or python. Or anything that's cross platform and low impact. (and by that I do not mean Java - sorry guys, the nightmare that is installing Java environments is a subject of an upcoming rant)
Powered by ScribeFire.
Subscribe
0 Comments