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

[Dave Korn]

Ralf Wildenhues wrote:

> Yeah, I was merely arguing for the testsuite file name; sorry for the
> confusion.

  NP.  Renamed to bindir.at.

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

  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?

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

> I think it would be good to see test results for MinGW and GNU/Linux,
> but it's sufficient to run the new tests only,
>   make check-local TESTSUITEFLAGS='-v -d -x -k bindir'
> 
> or so, depending on how you name your tests.  (I can run these tests.)

  Thanks, I'll take you up on that offer when the respin is complete.

>>>> diff --git a/Makefile.am b/Makefile.am
>>>> old mode 100644
>>>> new mode 100755
>>> Your files suffer from mode changes.  

  I found a workaround.  I think the perm changes were in non-unixy parts of
the ACL and caused by using a windows native editor.  Copying correct perms
across from one of the other files in the same directory using 'chmod
--reference=...' shuts git up about the perms.

> Certainly.  My (arguably weak) point is that the Libtool manual is
> pretty generic; there is currently literally no mention of the terms PE
> or COFF at all, not even DLL is explained (note though that there is a
> pending patch from Chuck that documents some w32-specific issues).  It
> simply seems a bit of a jump to start off this way.  What about
> something like
> 
>   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?

>>>> +# func_relative_path libdir bindir

>>> gnulib-tool has a function func_relativize.  Can we just reuse that
>>> (and make it fast)?

> Sure.  However, if you want something that works with ../, then the
> gnulib-tool code is worth looking at.  Just a suggestion, you know.

  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.

>>>> +  -bindir BINDIR    specify path to $prefix/bin (needed only when 
>>>> installing
>>>> +                    a Windows DLL)
>>> Again, please don't give the impression that users should pass this for
>>> w32 only.
>>   Okeydokey, will snip the phrase in parentheses.
> 
> The $prefix/bin isn't necessarily correct either, imagine the user
> typing './configure --bindir=/some/where/else/bin'.  :-p

  Heh, gotcha, will reword entirely.

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

>>> Likewise in the test below.
>>   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?

    cheers,
      DaveK