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]

Re: [article] trimming down autoconf's configure scripts by using pkg-config


* 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]