<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Wed, 2010-12-22 at 00:18 -0500, Trevor Woerner wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Sat, Dec 18, 2010 at 11:14 AM, Gaetan Nadon <<A HREF="mailto:memsize@videotron.ca">memsize@videotron.ca</A>> wrote: > On Thu, 2010-12-16 at 22:48 -0500, Trevor Woerner wrote: > Instead of doing all the "EPREFIX_SET" stuff, couldn't we just do: > > + ${EPREFIX:+--exec-prefix="$EPREFIX"} \ > > and leave off the rest of this patch? We don't really need another > variable whose defined or undefined state lets us know whether EPREFIX > is defined or not :-) > > That's what I first thought, then I realized the difference between $PREFIX > and the other ones. $PREFIX is a mandatory variable while the others are > not. We need the value from EPREFIX to compute the default values for other > variables, but we don't want to emit a command line with --exec-prefix on > each module. Okay, ignoring this specific variable (PREFIX), for the rest of your patches in this series would it be possible to remove the <VARIABLE>_SET logic and just use the ${<VARIABLE>:+--what-have-you="$<VARIABLE>"} ? I find all the extra VAR_SET code extraneous. </PRE> </BLOCKQUOTE> I need to know if the variable was set by the user or if it was assigned a default value by build.sh. Why? Because I always need those *DIR variables to hold a value, either default or user supplied. Case in point: <PRE>     LD_LIBRARY_PATH=${DESTDIR}${LIBDIR}${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH} </PRE> LIBDIR is either supplied by user or assigned the default value EPREFIX/lib. EPREFIX is either supplied by user or assigned the default value PREFIX. And I don't want to emit a --libdir or --exec-prefix unless the value is supplied by the user whether it is different or not from the default value. <BLOCKQUOTE TYPE=CITE> <PRE> In the specific case of PREFIX: > I did not want to invoke each module with a long list of --what-have-you > when they are all default values. In fact, I was thinking that perhaps we > should not make PREFIX mandatory. The configure script has a default value > usr/local when none supplied. That a separate question of course. Yes, I agree. Following along the lines of my reply to your other patch (making PREFIX available from the environment) I agree that it would be nicer to follow the pattern of all other ./configure scripts: the prefix is not a required argument, assume /usr/local unless told otherwise. </PRE> </BLOCKQUOTE> Ok, I'll do that. It may be a bit surprising for users who forget to supply the "prefix" argument. The script used to fail, now it won't anymore. That's why I hesitated. This is how ./configure works if you omit --prefix. But I expect many will be happy not to have to type this in all the time. <BLOCKQUOTE TYPE=CITE> <PRE> > Currently, all modules are invoked with --libdir even when the default value > is used, and that's bugging me. The user should be able to switch back and > forth between build.sh and configure for a particular module and not see a > different config.log which would trigger an investigation. How does he know > it is equivalent and not a script bug. I would approve of such a cleanup. But that's just me :-) </PRE> </BLOCKQUOTE> I am confident about this one. It was a side-effect rather than the intent. Thanks for the review. I am hoping to hide all these details from the user. He should be able to just read the help and figure out how to use the script and not have to read the code to understand available features. </BODY> </HTML>