This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
* Marius Groeger <mgroeger@sysgo.com> wrote: <snip> > I think this article is to some extend spreading FUD. Autoconf is > primarily a facility allowing software to compile and run on > *different* operating systems. Yes, this was the motivation for autoconf. But it *does* carry around at lot of fixes for buggy stuff. BTW: I'm talking about the whole autoconf methodology (including the rest of the autotools package). Just have a look at libtool ... > Not being POSIX compliant is not synonymous with being buggy. No, just for platforms which claim to be POSIX compliant. <snip> > Having said that, I think the bigger problem with autoconf is the > inter-dependency of the tools and the .am/.in scripts. Not having the > "right" version (note I'm not saying the "recent version"!) often is a > PITA. Also, as you correctly pointed out in your article, actually > running certain tests is complete nonsense in a cross situation. The idea to try to compile dozens of things to find out the necessary information - by every single package - is crap, IMHO. Better define clear interfaces, which may be present or not, and write wrapper packages, which simply provide these interfaces (at least as a dummy if the platform already does the rest). Of course these wrapper packages may use an auto-detection for their own, but after installation, its simply there, by definition. Its the job of the wrapper package's developer to make sure, it's working evrywhere, not the job of the other's people nor the buildsystem. Imagine, for some reason, this auto-detection fails (for crosscompiling/ embedded people not quite unusual), its not easy to fix it - often manual hacks either in configure scripts or deep diving into autotools is necessary for that (ie. I had to completely rewrite libtool to make it work for me). Once these things are moved out to separate packages, you can fix *this single* package or maybe sometimes write an complete replacement, and nothing else has to be touched anymore. BTW: 90% of the esoteric autotools stuff wouldn't be necessary, if we'd use an strictly defined wrapper for toolchain commands, which is adopted for each platform once and for all. Again: an central point for all the platform dependent stuff, not redundantly in each package for its own. http://wiki.metux.de/public/Universal_Toolchain cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact@metux.de cellphone: +49 174 7066481 --------------------------------------------------------------------- -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- --------------------------------------------------------------------- -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |