Re: I got an autoconf big improvement to make :]

[Itzhak Avraham]

Hello and good day! : "Hmm, are you sure?  I think I've seen systems 
where 'find /' takes hours " They just wouldn't use that option then [like I 
said : disabled by default]. Also, if we're continuing that that thought 
after ./configure is over, it can point us out to what he needed to search 
and what he found eventually (using whereis, which or locate) 
and it can post yes/no/other option after configure finished, to every found 
program (so you can open another shell and search if it's the right program 
or not very quickly[if it's the right version, etc]).

Something like that :
./configure --search-missing=true is running and oops : 
"Some programs were missing :
libmp3lame.so were missing, used library  (/usr/lib) instead of default 
(/usr/local/lib) [YES, OTHER([]), ignore]" if you do not pick yes, you can 
just write a path instead (while ./configure is running!!) it would be great, 
cause in the current state you got to look on ./configure --help (if exist) 
for every missing program, if you pick yes, it means it found the good path 
for you, using the whereis,which or other options, and configure can keep 
running, until it found the next problem.

I hope I've explained myself better this time using a real-life example.
Anyways, I'm happy you took the time to read my e-mail!!!

I'd be happy to get a response on this one as-well, I really think it's an 
awesome idea, and that's why I'm writing this letter to you.



Itzhak Avraham.

On Sunday 19 November 2006 09:07, Ralf Wildenhues wrote:
> [ dropping config-patches and autoconf-patches as unrelated ]
>
> Hello Itzhak,
>
> Thanks for the suggestion.
>
> * Itzhak Avraham wrote on Sat, Nov 18, 2006 at 09:46:46PM CET:
> > Lets say I'm starting a program which can't find liblamemp3.o file, if I
> > run the ./configure --search-missing=true option it will look for
> > lib-lame with whereis/which lame it should find it in no time, also, if
> > didn't find, it can use the find / -name "lame" -print option for
> > example.
> > It might increase configuration time so it should be disabled by default,
> > but making it enable can save hours of searching each package that
> > couldn't be found by ./configure.
>
> Hmm, are you sure?  I think I've seen systems where 'find /' takes hours
> itself.
>
> Even if that weren't an issue in itself, please consider that users may
> have several incompatible versions of a library installed somewhere,
> that hosts may be multi-ABI (x86_64), that cross-compile libraries would
> typically be found as well, and that (for now) last but certainly not
> least you typically need to find the header files that match those
> libraries you happen to have found.  The latter isn't trivial at all,
> even if it may sound so to you.
>
> So no, I don't think this would be an improvement.  Anyway consider
> using 'locate' rather than 'find' next time you're looking for
> something.  Or, rather, pick your packaging tool of your distribution
> and have it look for a package that contains the library in question,
> including all dependent libraries.
>
> Hope that helps.
>
> Cheers,
> Ralf