libtool-patches
[Top][All Lists]
Advanced

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

Re: building HEAD needs GNU make


From: Eric Blake
Subject: Re: building HEAD needs GNU make
Date: Sat, 24 Feb 2007 07:27:50 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[adding m4-discuss - this was
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/7289]

According to Ralf Wildenhues on 2/24/2007 7:13 AM:
>> * Eric Blake wrote on Sat, Feb 24, 2007 at 02:03:43PM CET:
>>> According to Ralf Wildenhues on 2/24/2007 5:55 AM:
>>>> Our convoluted build rules in HEAD's Makefile.am currently pretty much
>>>> require GNU make. [...]
>>> That's a bit of a shame: since the eventual M4 2.0 depends on Libtool, you
>>> are now adding one more hard dependency into the mix when bootstrapping a
>>> non-GNU system to support the GNU toolchain (with M4 1.4.x, the system
>>> make and system C compiler were adequate).[...]
> 
> There may be a misunderstanding here: M4 2.0 itself does not need GNU
> make to build.  Well, it does, but not because of M4 using Libtool.

Let me recap my original observation.  Currently, in order to get GNU
Autoconf onto a non-GNU system, working from GNU tarballs, you need:

m4-1.4.x and autoconf 2.6x:

system make
system C compiler
GNU m4 1.4.x tarball
perl
autoconf 2.6x tarball

the future autoconf 3.0:

system make
system C compiler
GNU make tarball
libtool 2.0 tarball
GNU m4 2.0 tarball
perl
autoconf 3.0 tarball

It is the addition of GNU make as a prerequisite to libtool 2.0 and m4 2.0
that is depressing, but not necessarily a show-stopper (since most people
installing the GNU toolchain on non-GNU platforms already intend to
install GNU make).

> Rather because of the brain-dead^W^W^Whelpful-for-development stamp-vcl
> updating rules that M4's Makefile.am also has.
> 
> Not sure if your comment implied that you knew this or not, so I guess
> I should mention this.

Ouch.  I basically copied the current stamp-vcl rules in M4 head from
libtool.  So at this point, a solution for one project is the solution for
both.  Maybe at some future time I will be able to look into it more.  Is
it also worth breaking the stamp-vcl updating rules into a GNUMakefile, so
that development gets to use them, but released tarballs do not need to
see those confusing rules?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF4Etm84KuGfSFAYARAptxAKDPnEJbJ8507trtF4O2l3WQAfSJwQCeI75z
TYuLxQ7Je8423cl+E9WuROo=
=ZnrX
-----END PGP SIGNATURE-----




reply via email to

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