autoconf
[Top][All Lists]
Advanced

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

Re: proposal to fork the build-tools projects


From: Tom Tromey
Subject: Re: proposal to fork the build-tools projects
Date: 20 Oct 2002 15:15:46 -0600
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

>>>>> "Soren" == Soren A <address@hidden> writes:

Tom> Of course you can.  Just write a Makefile.in that uses GNU make
Tom> features.  Nothing requires you to use automake.

Soren> I'm being a little circumspect in my phrasing ("people think")
Soren> because I cannot point to exactly where a document might exist
Soren> that says this.

I don't think there is such a document.  And, in fact, GNU packages
exist that require GNU make: glibc, inetutils, and even gcc (libjava
currently requires GNU make).

Soren> But when I go this route some people who comprise peers giving
Soren> me critique and/or comprise some of my user base, will cry that
Soren> "it's not portable because it requires the user to have GNU
Soren> make installed."

Yes.  Have you tried asking these people why they criticize?  Perhaps
they actually want to use some other make.  Or, perhaps they just
repeat this without a need, in which case presumably you could ignore
them.

Soren> What I am saying is that this is an instance where supporting
Soren> people's backwardness make package maintainance / development
Soren> *much* more difficult.

It's true that sometimes it is much more difficult.  We gave up in
libjava (more precisely, it has never been important enough for us to
bother to solve the problems).  For the majority of packages, however,
I disagree that this burden is very great.  In fact it is largely
borne by the automake developers, not the package maintainers.
libjava here is an extreme counterexample, doing things that very few,
if any, other packages actually do.

Tom




reply via email to

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