Re: FYI: latest "official" cygwin libtool

[Peter Rosin]

Den 2009-02-26 05:39 skrev Charles Wilson:
> Peter Rosin wrote:

*snip*

> > Your resulting code is e.g. in some cases setting LT_AR to:
> > LT_AR='$(SHELL) $(top_builddir)/libtool --quiet --mode=ar'
> > but your libtool script does not support --mode=ar
>
> Yep. The patches/commits weren't quite as independent as I thought, and
> some that I pseudo-cherry-picked depended on others that I didn't.
>
> > However, I'm not sure it is a wise thing to feed --mode=ar to the
> > wilderness
> > without an "ok" on the interface from at least one libtool maintainer?
>
> Meh. Cygwin doesn't use it, and it's broken so nobody will actually be
> ABLE to use it, so I might get some complaints on the cygwin list.  But
> I doubt any of those complaints will show up on this list; and if they
> do, just blame me for pushing untested patches into the wild and tell
> the OP to check the real pr-msvc branch if they're really interested.

You seem to think that the libtool you release in cygwin is limited to
cygwin users. That is not the case. When some upstream package maintainer
actually uses cygwin for development (I do), libtoolizes his/her package
with your patches (I don't, but that's only because I happen to know
there's a difference), releases a tarball, then every end-user of that
package gets your patches. I think you have to consider that...

> > Note that I made a mistake when I commited [2]. It was never intended to
> > go into the pr-msvc-support branch without the above "ok" [4].
>
> Oh. Didn't realize that.
>
> > And the 07- patch seems to break ordinary crosses. 
>
> Well now, that /would/ be bad.
>
> > My version assumed that
> > the toolchain is an ordinary cross toolchain which understands $build
> > paths,
> > except in cases where it knows it doesn't (i.e. $host=mingw, $build=mingw).
> > Your version assumes that the toolchain is not ordinary, but instead one
> > that understands $host paths (at least when $host is mingw or cygwin).
>
> That wasn't my intent.  I was attempting to add the caching behavior
> (which, because of autoconf limitations, requires a whole separate
> case...esac tree from the to_host_path_cmd tree: you can't cache two
> different variables at once).  But I hoped that, while using the
> different m4 code structure, the behavior stayed the same as yours.

Hmmm, I now realize that I was confusing your patch with my unpublished
rework of the patch that you found in the preview git tree. My reworked
patch looks like this (I.e. it's no longer intertwined with the to_host
check):

+AC_MSG_CHECKING([how to convert $build paths to toolchain format])
+AC_CACHE_VAL(lt_cv_to_tool_path_cmd,
+[#assume ordinary cross tools, or native build.
+lt_to_tool_path_cmd=func_noop_path_convert
+case $host in
+  *mingw* )
+    case $build in
+      *mingw* ) # actually msys
+        lt_cv_to_tool_path_cmd=func_msys_to_mingw_path_convert
+        ;;
+    esac
+    ;;
+esac
+])
+to_tool_path_cmd=$lt_cv_to_tool_path_cmd
+AC_MSG_RESULT([$lt_cv_to_tool_path_cmd])
+_LT_DECL([to_tool_path_cmd], [lt_cv_to_tool_path_cmd],
+         [0], [convert $build paths to toolchain format])dnl
+AC_SUBST([to_tool_path_cmd])dnl

This mistake of mine made it hard for me to understand why you had
fleshed that out with all the other cases from the to_host case-tree.
But of course you hadn't fleshed out anything, you wrote the
cache check independently, and it looked so similar to my version
(we both copied your to_host code) that I was confused.

> However, because I didn't pseudo-cherry-pick the patch which actually
> USES the new func_to_tool_path function...I didn't actually *break*
> anything in my build.

Right, now I see. You have not included enough to make it matter. Sorry
for the panic attack...

> But I can see that if you accepted my 07- patch, it would break your
> pre-existing USES of func_to_tool_path.
>
> However, the "fix" to my 07- patch is just a couple of one-liners, right?

See above :-)

*snip*



The patches in pr-msvc-support and in my preview git tree are not
independent, even when they touch the same area, for this reason:

The patches *in* pr-msvc-support have been "approved" by some libtool
maintainer (read: Ralf) (not counting the 4 patches that I pushed
by mistake). Then there are patches waiting for review to get into
the branch (or master), and lastly there are patches that depends on
external patches not yet fully reviewed. So, three classes:

        a) in the branch (except 4 patches belonging in b)
        b) waiting for review
        c) depending on externals

In the case of the AR patches there is, as you've discovered, patches
in all of a, b and c.

Also, when something has gone into the branch, I'm hesitant to change
it. I feel that it is much better to just add patches on top in order
to preserve history. This makes it harder to cherry-pick, of course.

The complexities and the length of my patch queue is not all my fault.
Believe me, noone would be happier than me if it wasn't such a mess.

Cheers,
Peter