libtool
[Top][All Lists]
Advanced

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

Re: cannot build from git/no daily snapshots


From: Peter Rosin
Subject: Re: cannot build from git/no daily snapshots
Date: Tue, 18 Sep 2012 09:53:20 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1

On 2012-09-18 03:33, Gary V. Vaughan wrote:
> Hi Bob, Peter,
> 
> On 17 ก.ย. 2012, at 23:22, Bob Friesenhahn <address@hidden> wrote:
>> On Mon, 17 Sep 2012, Peter Rosin wrote:
>>>>
>>>> The 'm4' on this MinGW install is not a blessed version and a simple 
>>>> build/install
>>>> of latest m4 produces an m4 which does not work. :-(
>>>
>>> Was that an MSYS-m4 or a MinGW-m4? Assuming it was MinGW-m4, I
>>
>> The one that came with the MSYS install was surely a MSYS-m4 and the one
>> I built was surely a native Windows m4.  The native Windows m4 I built
>> likely produces/consumes Windows text line terminations and that is why
>> it did not work (even though libtool configure accepted it).
> 
> bootstrap (and Autoconf from where I cribbed the m4 worthiness test)
> only check the supplied m4 has a version number greater than or
> equal-to the minimum known working version.
> 
> The real bug here seems to lie somewhere between modern m4 not building
> properly on Windows, and Autoconf requiring a newer m4 than supplied by
> MSYS/mingw.

There is no evidence that modern m4 does not build properly on MSYS, which
is what is interesting. A MinGW-m4 is not all that interesting in the
autotools context. What Bob tried (a MinGW-m4) was simply wrong, but the
reason for the attempt was surely because he had no tools to build MSYS
binaries installed. Very few do, and I suspect that most that do have them
installed don't know exactly what they're doing...

>>> think it is too much to ask to require MSYS-tools for simple
>>> libtool hacking. If it was MSYS-m4, even worse. And the suggestion
>>> to build a tarball and use that when developing for MinGW is
>>> just asking too much. Insane work flow.
> 
> Do people really want to do full-bore Libtool development (as opposed
> to using it to develop an occasional bugfix) on Windows?  Why?!?  Not
> being flippant here, but I'd be surprised to find that the kinds of
> people who want Libtool to work on Windows, and know enough about
> Libtool to keep it working don't have access to a pleasant OS for
> actual development, with Windows relegated to being a test machine.

I don't know if my contributions count as more than an occasional bugfix,
but I weigh-in at 100+ commits. I did all of that on Windows. I used the
occasional Linux VM, but that was exceptional. I also tested on more
esoteric systems over the Internet, but virtually all coding was done
on Windows. I don't like doing development over the Internet or in a
VM, it's too flakey for me. Maybe I'm just stupid?

> For all the Unix architectures I have access to, my workflow is to
> put an unpacked `make dist` tarball on an NFS drive, and make VPATH
> builds in a subdirectory for each machine.  Windows has some network
> mounting facility too, so that doesn't seem insane to me.

My workflow is to bootstrap on Cygwin (which is much more up to date
in the tools department) and just build on MinGW in the same checkout
but with a different build dir. What I don't want is any extra steps
such as being required to build a tarball on Cygwin just to test
MinGW.

>>> You have to remember that these extra steps lands on the people
>>> spending the most time fighting (and waiting for) the build
>>> system. I haven't touched Libtool in a while now, I wonder why,
>>> but it was not a conscious decision. Maybe it wasn't fun anymore
>>> for some reason? These changes does not seem attractive though.
> 
> What changes are you referring to?  If there is some particular
> changeset(s) that have broken previously working Windows support,
> then we should definitely figure out why, and fix the problem.

Bob wrote this:

        "Please make it so that it is possible to use a source tree
        which has a .hg directory even if there is no 'git' program
        available and even if autotools are not the exact same
        version used to bootstrap the tree."

Assuming he meant a .git directory, this is something I need for my
workflow and something which has worked, so it is a regression. I'm
not sure if I want to --skip-git in my bootstrap, because then the
Cygwin side of things are not "as usual".

Cheers,
Peter




reply via email to

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