bug#8557: libtool must not depend on existence of system '/usr/lib*/*.la' files

[Jason Vas Dias]

On Thursday 28 April 2011 12:59:05 Mike Frysinger wrote:
> > And I'd still like an answer to the basic question "why is libtool doing so 
> > much on Linux
> > when gcc gets it right on its own" ?
> 
> your view of libtool is clouded by your very narrow focus on recent
> versions of gcc/Linux targets.  libtool scales to many many more
> targets, and its complex system is designed to handle severly
> deficient targets.  albeit at the cost of being more complex than
> necessary for some modern/sane targets.
> -mike

But I, as the end user and "distro maintainer" of my own distro, want to 
produce a compatible
version of libtool for linux for use on it that does not do anything too 
complicated unless it needs to .

I've always greatly admired autoconf, automake and libtool for their ability to 
build and install 
software on such a huge variety of platforms, but always hated trying to get 
them to build
and install software that is truly optimized for only one OS and toolchain .

With a "one size fits all" approach, it is too easy to make all software 
perform equally poorly on all platforms -
I'm not saying autoconf / automake / libtool does this, but it enforces alot of 
complicated configuration operations on platforms where
literally typing 'make c.o' where 'c.c' exists will do the job without anything 
else at all (no Makefile required even) .

I'm developing a 100% GNU make(1) and bash(1) and coreutils dependant 
replacement for the "configure" step - NO other dependancies required -
that will generate  'Makefile's and ./libtool with very simple commands if it 
finds itself to be running on a "quick configure platform" , it will skip 
configure 
and just generate simple autoconf generated files.
I have a make library that can source and execute m4 configure macros,  and 
could make it construct a "configure" script and "libtool" script in make 
"define ... endef"s that can be dumped to files or sourced . Personally, I 
prefer programming in GNU make(1) and using macro processors such
as cpp or autotext or the shell to programming in m4 , and there is no reason 
why this shouldn't be permitted on platforms with a fully functional
GNU development tools and utilities toolchain .

I'll post the results to address@hidden or whatever it should be sent when this 
is complete and fully tested (for Linux at least).

All the best,
Jason