[Top][All Lists]

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

Re: pr-msvc-support merge

From: Peter Rosin
Subject: Re: pr-msvc-support merge
Date: Sat, 12 Jun 2010 00:49:18 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100317 Thunderbird/3.0.4


Ok, let's take a step back. This is no longer really merging
work from the branch, so since A) using MS lib as archiver isn't
essential for MSVC support (at least I don't think so, I can't
remember any case where binutils ar hasn't worked for me, but
ar creates archives that are different so I don't really like
the situation) and B) by the looks of it it will have little to
do with patching libtool anyway, I think it might be better
to leave the archiver work behind for a bit.

Some points:

By bringing a standalone script to the automake list that will
(at the moment, and for the foreseeable future) only be of use
if you want to use MS lib as archiver, but will still add
another file to "all" packages, I feel that there is a risk that
the benefit will be deemed too small when compared to the cost.
ltmain is already large and a few extra lines will not be noticed
by that many people.

If another funky archiver is found, which will need wrapping, the
needed "defunkying" should go into the same standalone script,
anything else would be a failure from my pov. But then you end
up with the problem Ralf mentioned (how to communicate from
configure to the wrapper how the wrapper should behave). That
problem is easily solved if the wrapper lives inside the libtool
script. Similarly, since we need to teach libtool how to convert
posix $build paths to $host paths anyway, if the wrapper lives in
libtool we get the infrastructure for that for free when it's time
to fix this for lib.exe. If the wrapper is standalone, it will
need to figure these things out on every invocation (probably doing
a bunch of painful forks) or it will need help from somewhere (i.e.
configure via make à la depcomp).

The above may sound as if I'm opposed to moving the script to
automake, but I'm not. I'm mostly afraid of the script ending up
where the cccl script - or should I say script_s_ - ended up.

The good thing with a standalone script is that it is usable w/o
some/all autotools. Having the script work w/o autoconf/automake
is not terribly important, so falling back to the depcomp variable
passing scheme when something is too painful to figure out at
runtime is workable, methinks.

Attaching a very rough first cut, but I don't intend to work on
this at the moment as explained at the top. I'll post a mail
addressing the next patch on the branch soonish instead.


Attachment: ar
Description: Text document

reply via email to

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