libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dave Korn
Subject: Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Date: Sat, 15 Aug 2009 14:29:21 +0100
User-agent: Thunderbird 2.0.0.17 (Windows/20080914)

Ralf Wildenhues wrote:
> in addition to what Eric already documented:
> 
> * Dave Korn wrote on Fri, Aug 14, 2009 at 01:34:18PM CEST:
>>   Still finishing it off and getting it tested, but while that's going, 
>> here's
>> a preview of the path canonicalisation function as I've got it so far; let me
>> know if I've done any major no-nos please!
> 
> Do you cope with paths starting with // (these can be special on Cygwin,
> you may not remove the second / in that case)?  (If anything, this is
> only a rather minor no-no however, and I have no idea whether we treat
> it consistently elsewhere in libtool.)

  Hah.  I collapse them of course.  Doh.  I'll see how I can preserve them.

  The other possible problem is DOS-style paths.  I don't know if libtool is
supposed to handle them or not.  It certainly looks like
func_dirname_and_basename would fall down badly on them, but I don't know if
that's just a happenstance of the way it got autogenerated on my platform
where they aren't used?  I couldn't find anything in the manual referring to
drive letters.

>> # func_normal_abspath path
> 
> Capitalize PATH here, please.  Maybe also s/PATH/FILE/ throughout the
> comment, to avoid mistaking it with the $PATH environment variable?

  Will take the latter option.

>> # Remove doubled-up and trailing slashes, "." path components,
>> # and cancel out any ".." path components in PATH.
>> #             value returned in "$func_normal_abspath_result"
> 
> Missing a statement that an absolute path is returned, that would be
> nice.

  Will add.  (The name of the function is supposed to be a hint, but it can't
hurt to be explicit!)

> One would hope for a followup patch that factorizes all the forks
> in this function for SUSv3 shells that provide ${var##...} etc.
> Otherwise, if this function is used more than once per libtool
> invocation, it will be a major speed bump in a typical build.
> (IOW, you don't need to address this, but it ought to be looked at;
> I might do it sometime.)

  Thanks, I still haven't learned all the internal structure of libtool and
wouldn't know how to do that without a bunch more research.

  Respin is nearly complete now, just these minor tweaks to get through and
give it some testing.  More later.

    cheers,
      DaveK





reply via email to

[Prev in Thread] Current Thread [Next in Thread]