Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.

[Ralf Wildenhues]

* Dave Korn wrote on Thu, Aug 13, 2009 at 09:19:49PM CEST:
> Ralf Wildenhues wrote:
> 
> >>   I can rename it and adjust the tests so they run on all platforms, but 
> >> make
> >> sure the library /doesn't/ get installed to bindir on non-PE platforms.  
> >> Ok?
> > 
> > Why would that additional test be necessary?
> > 
> > The general idea (however poorly executed) is that the test suite should
> > need as little adjustment as possible when we add support for new
> > platforms.  Likewise, ltmain should not require much adjustment except
> > to accommodate actually new semantics; only libtool.m4 and ltdl.m4
> > really ought to carry all the system-specifics, and they should be
> > transported into the libtool script through the bunch of variables.
> > 
> > Yes, this idea is pretty poorly executed ATM.
> > 
> > But in this particular case, I would argue that either you look at the
> > libtool variables shlibpath_var and hardcode_action for "PATH" and
> > "unsupported".  And even then, I wouldn't really want to check for
> > presence of a particular file in $bindir, but I'd check whether a
> > program executable installed in $bindir, and linked against a library
> > (that should have its DLL installed in $bindir on applicable systems)
> > will start and run correctly.  Written this way, however, you don't
> > need to delimit this particular test to any subset of platforms: things
> > will work on any other system, too, by way of libtool linking semantics.
> 
>   Okay, I get what you mean.  I agree with the first part (using shlibpath_var
> and hardcode_action rather than tests of specific OSs), but I beg to differ
> about the second.  Checking if the program starts and runs correctly isn't
> quite the same thing as checking if the parts were installed precisely where
> the application coder instructed libtool to install them.

True.

>  It's an indirect
> test, and for instance would false positive if someone on a windows platform
> had /lib in their PATH.  There might also be platforms where it didn't matter
> functionally which of /bin and /lib a library got installed into, but there is
> a packaging standard that says what goes where.  Now, okay we can always reset
> the PATH for the test, but if we're trying to do something that works as-is
> for unanticipated future systems, could we ever be sure we'd caught every
> environment variable or whatever that might make this indirect test produce a
> false result?

Probably not.

>   For these reasons, I'd still prefer to test that the precise files we expect
> get installed to the precise locations we require.  Doing it that way (but
> with the first part of your suggestion) would still be fully cross-platform
> and future-friendly, wouldn't it?

Seems ok.  Thanks for persevering.

> > Yes, you mentioned that.  What I meant was a followup semantic change
> > in Automake.  Assume a Makefile.am with
>    [ ... ]
> > We have (1) now.  With (2), arbitrary --bindir and --libdir values
> > passed to configure by the user would be handled as well.  The question
> > is whether there can be cases when a developer would *not* want -bindir
> > to be passed automatically.
> > 
> > What do you think?  Even if there are such cases, we could arrange for
> > automake to output the -bindir before expanding $(LDFLAGS), so that it
> > would be overridable.
> 
>   The honest answer is I just haven't thought that far ahead yet.  I've only
> been thinking of this option as a partner to -no-undefined, but you've
> convinced me it might have relevance to a broader range of platforms.  In that
> context, it quite possibly would make sense for Automake to start adding it
> automatically.  But I haven't thought much about it yet.

OK.  Anyway it's fine to deal with this later on.

> >   Pass the absolute name of the directory for installing executable
> >   programs (@pxref{Directory Variables, , standards, The GNU Coding
> >   Standards}).  @command{libtool} may use this value to install shared
> >   libraries there on systems that do not provide for any library
> >   hardcoding and use the directory of a program and the @env{PATH}
> >   variable as library search path.  This is typically used for DLLs on
> >   Windows or other systems using the PE (Portable Executable) format.
> >   On other systems, @option{-bindir} is ignored.  The default value used
> >   is @address@hidden/../bin} for libraries installed to
> >   @address@hidden  You should not use @option{-bindir} for modules.
> > 
> > Anyway, this is really just a suggestion and I appreciate your criticism
> > of it.
> 
>   That seems fine for my purposes, I'll paste it in pretty much as-is, but the
> default parameter isn't necessarily libdir, it's just "where-ever you've
> specified as the output path for the .la file" + "../bin", isn't it?

Yeah; I tried to use @var{libdir} to indicate that (@var denotes a
metasyntactic variable, and renders differently) but that's probably too
subtle to understand, even with the "for libraries installed to ..."?
@var{libdir} is however the naming of the -rpath argument we use in
@node Link mode.

>   I took a quick look at it originally, thought it didn't really do anything
> different.  When you raised the ../ issue, I thought I'd take another look at
> it.  Turns out it requires both inputs to be relative paths relative to $cwd
> in the first place!  So rather than write a routine to relativize the paths so
> that I can pass them to func_relativize :-) I'll write something to
> pre-condition the paths (i.e. remove '.' components and cancel out
> 'component/..' pairs, remove any doubled-up slashes and trim any trailing one)
> and make it a separate func, it might come in handy elsewhere.

The path normalization has functions in gnulib-tool too, that you may be
able to reuse.

> >>> Your main doesn't need anything from libbar, and your libbar doesn't
> >>> need anything from libfoo.  Why have the libraries in that case?
> >>   I copied and pasted the testcase from elsewhere in the testsuite, without
> >> trimming it any.
> > 
> > Ouch.  Where from?  Another bug to fix.
> 
>   The test file as I originally submitted it was basically made of
> hacked-around bits of darwin.at.

Indeed, that looks fishy.  Thanks.

> >>   Well if I didn't have any library at all how could I check if it got
> >> installed to the right place?  Anyway, this too was largely cut'n'pasted.
> >> I'll trim them both down so that there's just one library and no main in 
> >> each, OK?
> > 
> > Sure, and please provide one function in the library, and refer to it
> > from the program.
> 
>   Well this depends what we agree about the design of the test, if you'll
> accept my theory that what I really want to test is which file goes where and
> whether that's correct, and that executability is only an indirect test of
> that condition, then I don't need to have a main exe at all.  For the reasons
> I explained above, I think we still get all the cross-platformness advantages
> even if we do it my way; will you accept it if I write it like that?

OK.  Well, can we compromise on _also_ having an executability test?
There are always so many things that can go wrong for execution, that it
is nonetheless useful to try that out, and for that, to have an
executable that calls a function from the library.

Thanks,
Ralf