| |||||||||||||
|
| |||||||||||||
More information on the X11R7.0/X11R6.9 releaseMore information on the X11R7.0/X11R6.9 releasePosted Dec 23, 2005 15:15 UTC (Fri) by Zarathustra (guest, #26443)In reply to: More information on the X11R7.0/X11R6.9 release by philips Parent article: More information on the X11R7.0/X11R6.9 release
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.
(Log in to post comments)
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.
|
|
||||||||||||