Archived
This forum has been archived. Please start a new discussion on GitHub.
autoconf makes things difficult to build
Hi,
Just registering my "nay" vote for any use of autoconf.
Firstly, autoconf in particular and the GNU autotools in general, are a rats nest of macros and incompatible technologies. If it works for you as a user, it looks fine. If it doesn't, and the developer hasn't provide a working set of options for your case, you are basically hosed - unless you like debugging M4 macros, the bizarre automake notation, make rules, shell script and assorted sed fragments not just one at a time, but concurrently - as it is layer upon layer of macros generating other macros that generate other macros! I think it's passed beyond the point where any one person can possibly understand all of it, and the subtle implications of the effects of the different tools on one another.
On my last project we used automake, autoconf and libtool as the basis for the build system - and to a man the developers wanted to take it out and burn it. We spent days sometimes making it do the simplest things, or *not* do the strangest things. Of course, given the amount of effort it would take to go back, it just couldn't happen. So we had no choice but to struggle on with the auto* junk.
Also, the philosophy of autoconf is wrong IMO. Playing guessing games to determine what is available on the target system is dangerous. I'd much prefer specifying it correctly up front and knowing exactly what's going on.
For example, the FreeBSD project uses just plain Makefiles. There's a top level Makefile that contains definitions that is included by all the rest, and you just modify that to say where you expect things to be.
In conclusion, to build Ice, you just make sure those few variables in Make.rules are set the way you want, and then type "make" followed by "make install". I don't see how it could be any easier than that.
If the Ice team wants to change to GNU autotools, that's their decision, but I just built Ice against a non-supported version of xerces and openssl, and I'm pretty sure if I'd tried that in an autotools build system I would have failed and given up in disgust.
And it absolutely will not make it any easier to port to Solaris or anywhere else. More difficult, if anything, if it turns out the autoconf M4 macros are broken for that platform, as is a frequent occurence in my experience
Phew, that was a long rant! Just my .02c worth.
Regards,
Derek.
Just registering my "nay" vote for any use of autoconf.
Firstly, autoconf in particular and the GNU autotools in general, are a rats nest of macros and incompatible technologies. If it works for you as a user, it looks fine. If it doesn't, and the developer hasn't provide a working set of options for your case, you are basically hosed - unless you like debugging M4 macros, the bizarre automake notation, make rules, shell script and assorted sed fragments not just one at a time, but concurrently - as it is layer upon layer of macros generating other macros that generate other macros! I think it's passed beyond the point where any one person can possibly understand all of it, and the subtle implications of the effects of the different tools on one another.
On my last project we used automake, autoconf and libtool as the basis for the build system - and to a man the developers wanted to take it out and burn it. We spent days sometimes making it do the simplest things, or *not* do the strangest things. Of course, given the amount of effort it would take to go back, it just couldn't happen. So we had no choice but to struggle on with the auto* junk.
Also, the philosophy of autoconf is wrong IMO. Playing guessing games to determine what is available on the target system is dangerous. I'd much prefer specifying it correctly up front and knowing exactly what's going on.
For example, the FreeBSD project uses just plain Makefiles. There's a top level Makefile that contains definitions that is included by all the rest, and you just modify that to say where you expect things to be.
In conclusion, to build Ice, you just make sure those few variables in Make.rules are set the way you want, and then type "make" followed by "make install". I don't see how it could be any easier than that.
If the Ice team wants to change to GNU autotools, that's their decision, but I just built Ice against a non-supported version of xerces and openssl, and I'm pretty sure if I'd tried that in an autotools build system I would have failed and given up in disgust.
And it absolutely will not make it any easier to port to Solaris or anywhere else. More difficult, if anything, if it turns out the autoconf M4 macros are broken for that platform, as is a frequent occurence in my experience
Phew, that was a long rant! Just my .02c worth.
Regards,
Derek.
0