| |||||||||||
More information on the X11R7.0/X11R6.9 releaseMore information on the X11R7.0/X11R6.9 releasePosted Dec 23, 2005 10:50 UTC (Fri) by Zarathustra (guest, #26443)Parent article: More information on the X11R7.0/X11R6.9 release
How sad to see X join the auto*hell insanity. Yes, the old monolithic build system was a mess, but why, oh why, did they have to switch to auto*hell during the process of breaking it up?
Here is a great t-shirt: http://www.cafepress.com/leuksman.7112875
(Log in to post comments)
More information on the X11R7.0/X11R6.9 release Posted Dec 23, 2005 11:16 UTC (Fri) by philips (guest, #937) [Link] Is there any other alternative?
More information on the X11R7.0/X11R6.9 release Posted Dec 23, 2005 12:03 UTC (Fri) by hmh (subscriber, #3838) [Link] Sure, "invented here" build systems that are no better than auto*, usually a lot more buggy because the author don't know anything about portability, and which are EVEN less understood than auto*.
Now, X.org imake was at least portable, but it is no easier to understand than auto*. "imake hell" is an expression that far predates "autohell".
More information on the X11R7.0/X11R6.9 release Posted Dec 23, 2005 13:52 UTC (Fri) by rknop (guest, #66) [Link] I've generally had no problems with automake. I've used it myself in code I've written, and kinda like it now that I'm used to it.
imake was something I learned to loathe early and loathed ever more as time went on.
I never fully figured out how to make imake work as a normal user, whereas I've done that frequently with autoconfig. (Whatever we're supposed to call the autohell thing.)
-Rob
More information on the X11R7.0/X11R6.9 release Posted Dec 23, 2005 15:15 UTC (Fri) by Zarathustra (guest, #26443) [Link] Alternative to what?
I have yet to find what problem auto*hell solves; it creates huge amounts of pain and suffering, that for sure; so if you are masochistic, it might be made for you, but I doubt your users will appreciate it.
As for "portability", now that has to be one of the greatest myths of the software industry. Auto*hell _hinders_ portability, it covers the portability problems with a layer of crud that then one has to drill thru when one has to port it anywhere.
Learn to write truly portable code, and learn to write proper make files, help reduce the pain and sorrow of the sad Unix world.
More information on the X11R7.0/X11R6.9 release Posted Dec 23, 2005 18:49 UTC (Fri) by arcticwolf (guest, #8341) [Link] I don't think you actually understand the purpose of the auto* tools.
They are not a magic wand you can wave at your code (existing or new) so it will suddenly become more portable, and they're not supposed to be, either. What they *are* supposed to do is collect all the knowledge of quirks of various platforms etc. in one place so that individual developers / projects don't have to worry about these things anymore.
If you want a good example of what they're supposed to help with, take a look at the Nethack sources. Nethack *is* pretty portable, even without the use of the auto* tools (naturally, since it predates those), but the portability parts at least are a heap of unmaintainable cruft, and if you're seriously suggesting that that's a good alternative to the use of the auto* tools, you're, well, quite out there.
That doesn't mean the auto* tools couldn't be improved, of course, but to say that they're worse than X11's imake or (even more) worse than no build tools at all just shows that you really don't know what you're talking about, and no links to silly t-shirts are going to change that.
More information on the X11R7.0/X11R6.9 release Posted Dec 23, 2005 19:53 UTC (Fri) by Zarathustra (guest, #26443) [Link] Auto*hell encourages people to write non-portable code with the illusion that auto*hell will cover their asses, but auto*hell fails miserably to do so, because auto*hell can only know about the platforms it has been tested on, and fails miserably everywhere else(oh, and don't get me started with crosscompilation).
Auto*hell basically makes sure that a package will be almost impossible to port to any new platform that auto*hell doesn't understand, and it even fails miserably in the platforms it's supposed to understand, because it tries to guess stuff it has no clue about and it just can't know, so it blows up, and you are left with >20.000 lines of generated make vomit to swim thru.
Just because most programmers have no clue about how to properly write portable code doesn't mean auto*hell is any better.
If you don't write portable code, auto*hell will only provide a false sense of portability and make it harder for others to make your code portable, and if you write portable code there is no use for auto*hell.
More information on the X11R7.0/X11R6.9 release Posted Dec 23, 2005 21:35 UTC (Fri) by pizza (subscriber, #46) [Link] So, I'm curious.
Have you ever written portable code?
What is your definition of "portable"?
Have you ever used the auto* tools?
What platforms do the auto* tools not understand? Do these exotic platforms come with their own build system?
Have you ever written a non-trivial software package that has optional components and multiple external dependencies that can be installed in arbitrary locations on the system?
Again, just curious.
Auto tools Posted Dec 23, 2005 23:03 UTC (Fri) by Ross (subscriber, #4065) [Link] I'm sorry but you aren't making any sense. I suspect you don't like auto tools due to a ban encounter with some program using them which wasn't written very well, rather than actual experience with it as a developer. What you describe is not how the auto tools work. They do tests dynamically to determine which features work/don't work, which libraries and headers exist, etc. at compile time. This means that you get rid of horrible, horrible code like:
#if defined(Linux) || defined(SYSV)
etc.
and replace it with:
#ifdef HAVE_SOMETHING_H
Which pretty much makes it work automatically even if you have never heard of the operating system which the program is being compiled for.
Maybe what you are talking about is the configure documentation that says not to use autodetection... ignore that. The config.guess stuff figures it out usually, and when not, picking a close match is easier than editing a .h file, like programs used to require before the auto tools (or even worse, an interactive script, like with Perl).
More information on the X11R7.0/X11R6.9 release Posted Jan 5, 2006 8:09 UTC (Thu) by ekj (subscriber, #1524) [Link] because auto*hell can only know about the platforms it has been tested on, and fails miserably everywhere elseAnd since auto* is only knows about and has been tested on around 10e7 different platforms, this is a serious limitation.
More information on the X11R7.0/X11R6.9 release Posted Dec 24, 2005 9:34 UTC (Sat) by dwmw2 (subscriber, #2063) [Link] Actually it's not clear that autohell would help nethack when it comes to cross-compiling. Nethack builds data files on the host and assumes that the endianness, structure sizes etc. are going to be compatible with the target. In my experience of cross-compiling projects, that's precisely the type of behaviour which made me come to loathe autohell. Not because such behaviour is mandated -- but just because it seems to be what comes naturally to most autohell users. They seem to like to run tests on the host and assume that the results will be valid for the target. Or compile for the target and then attempt to run the result on the host to find out the behaviour. Autohell is just a tool -- it isn't inherently evil. But it's a tool which is very easy to use badly, and I'd really prefer to see it die out. Portable code and sane toolchains would be a much better answer. I would personally pay for a licence for GNU ld for anyone and everyone who wanted it, if it meant that they'd then refrain from using libtool.
More information on the X11R7.0/X11R6.9 release Posted Dec 24, 2005 10:25 UTC (Sat) by jbailey (subscriber, #16890) [Link] Autoconf with gcc can detect a remarkable amount of things about the target system, including some information on structure size, and (IIRC) endianness.
Your comments make it seem like you perhaps haven't actually used autoconf and friends in the past half-decade.
More information on the X11R7.0/X11R6.9 release Posted Dec 24, 2005 17:10 UTC (Sat) by dmantione (guest, #4640) [Link] Actually, auto* is completely unusable for portability. The reason is itassumes Unix. I'll sum up some OS-es: Linux, FreeBSD, Win32, WinCE, NetBSD, AmigaOS 4, MorphOS, MacOS Classic, Mac OS X. Now, for how many platforms does auto* help? About half of them. In other words, auto* solves the portability problem for about 50% of the OS-es. Now 50% is pretty impressive, right? Not at all, since Unixes have a lot in common, the porting effort for the other OS-es is a lot more than 50% of the porting effort, in case you should want to support them all. To be able to build auto* crap on non-Unix systems, of which Win32 is one of the most common, one needs a Unix-emulation environment, like Cygwin. However, this does not produce native applications.
More information on the X11R7.0/X11R6.9 release Posted Dec 26, 2005 14:25 UTC (Mon) by alvherre (subscriber, #18730) [Link] Amazing how much a thread can drift from the original article. Did anybody take a look at why autotools were chosen, back when they were chosen? I remember reading an article about it, which mentioned that other build systems were considered but rejected for various reasons (SCons is the one I remember.) The X.Org developers didn't make an uninformed nor arbitrary decision.
About autotools themselves and non-Unix portability, let me point out that autoconf (but not automake) is used in PostgreSQL to produce native Win32 (MinGW) and Mac OS X binaries, besides the obvious Linux, various BSDs, Solaris, AIX, Irix, etc. At one point it supported QNX, BeOS and other systems as well, though those appear to be abandoned for lack of reporters (users with compiler access). So your comment about'em being Unix-only appears to be at least partially incorrect.
More information on the X11R7.0/X11R6.9 release Posted Dec 28, 2005 10:45 UTC (Wed) by dmantione (guest, #4640) [Link] Autotools are only usable outside Unix if you load a bunch of Unix junk,i.e. cp, mv, sed, awk, and other Unix tools onto the OS you port to which is effectively emulating Unix on such an OS. Besides that it is not fun it causes portability problems since those tools must be ported as well. There is no way to make Autotools use copy or move for example in Win32.
More information on the X11R7.0/X11R6.9 release Posted Dec 28, 2005 14:00 UTC (Wed) by hppnq (subscriber, #14462) [Link] Just a slight remark: autoconf and friends are mainly used by developers, as an ordinary user who wants to install a new piece of software you just run configure, so that's where your portability problems start.No need to make things more complicated than they already are.
|
|||||||||||