dirforbid.test and pr300-ltlib.test fail after
./configure
make
make check
cygwin on windows XP
uname -a = CYGWIN_NT-5.1 DPB2 1.3.10(0.51/3/2) 2002-02-25 11:14
i686 unknown
libtool 1.4e
autoconf 1.52
gcc 3.0.4
Attached is the results of
make check VERBOSE=x TESTS='dirforbid.test pr300-ltlib.test
Akim Demaille <[EMAIL PROTECTED]> writes:
> You miss one point: killing this impedance problem. When Autoconf adds
> new files, e.g., autom4te.cache, Automake is immediately obsoleted,
> because it does not remove this file.
That's not exactly a horrible failure mode. People can just add it to
On Wed, Apr 03, 2002 at 07:04:07PM +0200, Akim Demaille wrote:
>
> | Akim Demaille writes:
> | > What I'm doing now is buying my freedom. The freedom to extend
> | > Autoconf without 1. requiring from the rest of the world that they
> | > adjust their distclean rules, 2. requiring that Automake
Akim Demaille writes:
> What I'm doing now is buying my freedom. The freedom to extend
> Autoconf without 1. requiring from the rest of the world that they
> adjust their distclean rules, 2. requiring that Automake folks release
> a newer Automake etc., not to mention that it needs 1. writing
>
Aroma De Form
http://www.aromadeform.com/include/style.css";>
http://211.119.134.208:8080/servlet/LinkServlet?LRES_LSEQ=100&LRES_USER=aroma&[EMAIL PROTECTED]&LRES_RSEQ=big&URL=http://www.aromadeform.com";
target="_blank">http://www.aromadeform.com/news/event/i
On Wed, Apr 03, 2002 at 11:12:26PM +1000, Robert Collins wrote:
> As a secondary point, as a user, I'd love to see one of two things:
> * looser coupling between automake and autoconf, or
good
> * a single product.
bad (there's been no good come out of mashing automake into autoconf).
--
Tho
| Akim Demaille writes:
| > What I'm doing now is buying my freedom. The freedom to extend
| > Autoconf without 1. requiring from the rest of the world that they
| > adjust their distclean rules, 2. requiring that Automake folks release
| > a newer Automake etc., not to mention that it needs 1.
I think there are valid points to both the 'tools don't clean up after
themselves' and the 'autoconf and automake shouldn't be in lockstep'
arguments.
IMO autoconf will make life easier for both automake and non-automake
users by providing a clean capability of it's own. That in itself should
mak
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
>> configure.in:8: error: `Makefile' is already registered with
>> AC_CONFIG_FILES or AC_OUTPUT.
adl> Thanks! This is a bug in the testsuite that you can safely
adl> ignore.
adl> (Akim: any idea why CVS Autoconf does not print thi
Paul Eggert wrote:
>
> > Date: Tue, 02 Apr 2002 22:41:50 -0800
> > From: Dan Kegel <[EMAIL PROTECTED]>
> >
> > Clearly, one would also want cp --clean.
>
> "rm --clean" would be far more useful. I've often wanted that,
> usually right after I've removed the wrong thing.
>
> (Sorry, Akim, could
> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> Akim Demaille writes:
>> In fact, I think all the tools should provide some --clean. For
>> instance, the hair we have to clean the Texinfo related files have
>> nothing to do in Automake. It should be provided by texi2dvi and
> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> Akim Demaille writes:
>> And, as far as Automake goes, I don't think I'm making things worse
>> to its non-users. Nothing changes for them.
Peter> Possibly true, but try to keep a clean separation between
Peter> Autoconf and A
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
Russ> Respectively, I think you're significantly over-solving this
Russ> problem. Just document somewhere what files can possibly be
Russ> created and let the package author do what they wish with them,
Russ> write a make distclean rule or
13 matches
Mail list logo
