Akim Demaille <[EMAIL PROTECTED]> writes:
> Russ, you are member of this list, and as such, your opinion is not
> that of a regular naive user. Sure you can answer to me that you need
> to be an expert to use Autoconf, but then, I'm precisely trying to
> kill this.
There are a lot of things tha
Akim Demaille writes:
> Because I fail to see the advantage for Automake to have to clean
> itself, rather than asking the cleaning.
Automake already does all the other cleaning, so you could say it's quite
good at it. Autoconf hasn't done any cleaning so far.
> That's better to my eyes, also
> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> Akim Demaille writes:
>> Because I fail to see the advantage for Automake to have to clean
>> itself, rather than asking the cleaning.
Peter> Automake already does all the other cleaning, so you could say
Peter> it's quite good
Akim Demaille writes:
> I don't agree. The important part is that I, as a maintainer of the
> foo package, focus on my task, and be relieved of all these stupid
> details. It has to work for me, not the converse.
If a package maintainer wants to be relieved from stupid details, he can
use Aut
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>> From: Akim Demaille <[EMAIL PROTECTED]> Date: 02 Apr 2002 18:57:05
>> +0200
>>
>> it makes no sense at all the distclean a single directory, as
>> anyway you need to rerun config.status to re-enable this directory.
>> Of course, knowledg
| > So you are throwing away the non Automake users, and you lose the
| > ability to run ./configure --clean without Makefile (precisely after a
| > distclean).
|
| Why can't you do this:
|
| %% AC_CONFIG_DISTCLEANFILES(FILES)
| %% Clean FILES
| AC_DEFUN([AC_CONFIG_DISTCLEANFILES],
| [ac_distcl
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
Russ> 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.
Russ
Es schrieb Peter Eisentraut:
>
> 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.
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
>
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
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
Peter Eisentraut wrote:
>
> 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 the
> > like.
>
> But where does
> 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, couldn't resist)
Roger Leigh <[EMAIL PROTECTED]> writes:
> The average user won't know this. Subsequent recursive targets called
> from the top-level will now fail due to the missing Makefile, so it
> seems of dubious value to me too.
Not all distclean targets remove the Makefile. Not all of us use
Automake.
Akim Demaille <[EMAIL PROTECTED]> writes:
> It imposes quite some complications to maintain this possibility, and
> I'm not sure it's good. In addition, the semantics of distclean in a
> subdirectory being so fuzzy (to my eyes), that making it valid only in
> a top level directory seems reasonab
Akim Demaille <[EMAIL PROTECTED]> 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 the
> like.
Respectively, I think you're significa
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 the
> like.
But where does it stop? gcc --clean? ld --clean? touch
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.
Possibly true, but try to keep a clean separation between Autoconf and
Automake. Autoconf shouldn't have to know about removing files and such
things. Just
On Tue, Apr 02, 2002 at 12:39:00PM -0800, Paul Eggert wrote:
> It's OK with me if "make distclean" in a subdirectory is equivalent to
> "make clean", and you need to do "make distclean" at the top level to
> clean out all the stuff built by "configure" at the top level. This
> sounds to me like t
On Tue, Apr 02, 2002 at 06:57:05PM +0200, Akim Demaille wrote:
> [...] would it be grave that this subdir distclean
> triggers the top level's distclean.
It would be grave indeed:
- Principle of least surprise: I for one would be *very*
surprised if "make distclean" in a subdirectory start
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 02 Apr 2002 18:57:05 +0200
>
> it makes no sense at all the distclean a single directory, as anyway you
> need to rerun config.status to re-enable this directory. Of course,
> knowledgeable people will answer that ./config.status foo/Makefile
> d
On Tue, Apr 02, 2002 at 06:57:05PM +0200, Akim Demaille wrote:
> That's really my question. But does it really matter? I mean, it
> makes no sense at all the distclean a single directory, as anyway you
> need to rerun config.status to re-enable this directory. Of course,
> knowledgeable people
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
Paul> If you do it in "configure", you can successfully run "make
Paul> distclean" on one host, even for a build that was done on a
Paul> different kind of host. If I understand things correctly, under
Paul> the proposed design "config.stat
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> Another thing to think about is whether autoconf will ever have
Tom> files removed by `maintainer-clean' (or any other clean rule).
Tom> If so that will affect what we decide.
In fact, I think all the tools should provide some --clean.
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
Paul> distclean is a standard GNU make target, so I would think every
Paul> sub Makefile should support it.
That's what we do. I've never used this in a directory other than the
top level, but I think it is really up to the user to decide
Eric Siegerman writes:
> Another possibility is to do the cleaning in the Makefile as it's
> always been done, but have config.status provide the list of
> files. Something like an "@configure_targets@" macro for
> config.status to replace
That would have been my first thought, but you don't re
Eric Siegerman <[EMAIL PROTECTED]> writes:
> Another possibility is to do the cleaning in the Makefile as it's
> always been done, but have config.status provide the list of
> files. Something like an "@configure_targets@" macro for
> config.status to replace -- the catch being that, unlike othe
On Tue, Mar 26, 2002 at 10:30:22AM -0800, Paul Eggert wrote:
> > From: Akim Demaille <[EMAIL PROTECTED]>
> > Date: 26 Mar 2002 10:53:35 +0100
> >
> > * configure or config.status?
> >
> > It seems much simpler to do that in config.status, since, for a start,
> > it knows exactly what files were
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 26 Mar 2002 10:53:35 +0100
>
> * configure or config.status?
>
> It seems much simpler to do that in config.status, since, for a start,
> it knows exactly what files were created. configure should run in
> full before knowing what were the creat
In the list of things that we ought to do to de-correlate Automake
from Autoconf, there is the problem of the list of files to remove for
distclean. For instance, a recent bug report is about the
configure.lineno that configure might create if the shell does not
support $LINENO. In this case, A
37 matches
Mail list logo
