Re: [Xen-devel] [PATCH] tools: don't expand prefix and exec_prefix too early

[Matt Wilson <msw@xxxxxxxxxx>]

On Wed, Aug 08, 2012 at 08:53:28AM -0700, Jan Beulich wrote:
> >>> On 08.08.12 at 17:10, Matt Wilson <msw@xxxxxxxxxx> wrote:
> > On Wed, Aug 08, 2012 at 07:26:35AM -0700, Jan Beulich wrote:
> >> A comment in tools/configure says that it is intended for these to be
> >> command line overridable, so they shouldn't get expanded at configure
> >> time.
> > 
> > I'm not sure which comment you're referencing, or which command line
> > it's intended that you're able to override prefix/exec_prefix. Could
> > you point it out? What's not working?
> 
> The comment (around line 790 currently) reads
> "# Installation directory options.
>  # These are left unexpanded so users can "make install exec_prefix=/foo"
>  # and all the variables that are supposed to be based on exec_prefix
>  # by default will actually change.
>  # Use braces instead of parens because sh, perl, etc. also accept them.
>  # (The list follows the same order as the GNU Coding Standards.)"
> 
> The thing that wasn't working for me was passing
> --libdir='${exec_prefix}'/lib64 to ./configure.

Aah, OK. That's not something that I commonly see packaging control
files (RPM .spec / dpkg rules) do, but you're right that it's intended
to work.

> >> The patch is fixing tools/m4/default_lib.m4 as far as I can see myself
> >> doing this, but imo it is flawed altogether and should rather be
> >> removed:
> >> - setting prefix and exec_prefix to default values is being done later
> >>   in tools/configure anyway
> >> - setting LIB_PATH based on the (non-)existence of a lib64 directory
> >>   underneath ${exec_prefix} is plain wrong (it can obviously exist on a
> >>   32-bit installation)
> >> - I wasn't able to locate any use of LIB_PATH
> > 
> > I believe that the LIB_PATH portions can now be removed. I also
> > believe you're right that all of this can be removed. Did you attempt
> > that as well?
> 
> No, I didn't, not the least because I don't have the right autoconf
> version around and didn't dare to re-generate tools/configure
> myself (instead I did the resulting adjustments manually).

Indeed, it's a bit of a pain to set it up. I imagine that's why the
autogenerated files are committed into mercurial, which is a practice
I don't like...

> >> This will require tools/configure to be re-generated.
> > 
> > This is typically part of the same commit.
> 
> Sure, just that generally one wouldn't include generated parts
> in the patch, but expect them to be produced when committing
> (and as said above, I'd have to rely on the tools maintainers
> for this in order to not risk corrupting something).

Fair enough. :-)

Would you like me to take another pass at fixing this the "right" way,
by removing this bit altogether and adding lowercase variables to
tools/Config.mk?

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel