[PATCH modular 2/8] build.sh: add support for EPREFIX for architecture-dependent files

[Trevor Woerner]

On Sat, Dec 18, 2010 at 11:14 AM, Gaetan Nadon <memsize at videotron.ca> 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.

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.

> 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 :-)