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

Gaetan Nadon memsize at videotron.ca
Wed Dec 22 16:29:51 PST 2010

On Wed, 2010-12-22 at 00:18 -0500, Trevor Woerner wrote:

> 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.

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:


LIBDIR is either supplied by user or assigned the default value
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.

> 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.

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

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

I am confident about this one. It was a side-effect rather than the

Thanks for the review. I am hoping to hide all these details from the
He should be able to just read the help and figure out how to use the
and not have to read the code to understand available features.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101222/6cfe775b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101222/6cfe775b/attachment.pgp>

More information about the xorg-devel mailing list