dynamic and static libs with same src

[Kremp, Johannes]

i am using 

automake 1.6
autoconf 2.53
libtool 1.4b

on 

hpux 10.20.

i would like build a static and a dynamic library from the same sources. but
when automake runs i got follow messages:

automake: src/Makefile.am: object `rpxcmd.lo' created both with libtool and
without
automake: src/Makefile.am: object `rpxcnv.lo' created both with libtool and
without
automake: src/Makefile.am: object `rpxctr.lo' created both with libtool and
without
automake: src/Makefile.am: object `rpxuex.lo' created both with libtool and
without
automake: src/Makefile.am: object `rpxci.lo' created both with libtool and
without
automake: src/Makefile.am: object `rpxec.lo' created both with libtool and
without

with automake 1.5, autoconf 2.50 and libtool 1.4b is all o.k.

what can i do?
thanks for your help
johannes

0505 ¼Ò°³¿¹¿©

[0505]

Title: 0505-¼Ò°³ b3





º¯Ä¡¾Ê´Â ³» °³¼º¹øÈ£! 
 µ·µµ 
¹ö´Â Æò»ý¹øÈ£ °¡ ÀÖ½À´Ï´Ù. 0505-XXX-

http://www.urimaul.org/0505number/ 
(Ŭ¸¯!)Çà¿îÀÇ À̺¥Æ®µµ 
ÁøÇàÁßÀÌ¿¹¿ä. ÁÁÀº ±âȸ ³õÄ¡Áö ¸¶¼¼¿ä!
ÀÌ»çÇϰųª Á÷Àå/ºÎ¼­ 
À̵¿ÇÏ¸é ¸Å¹ø ¹Ù²ï ÀüÈ­¹øÈ£¸¦ ¾Ë¸®±â°¡ ³Ê¹« 
Èûµå½ÃÁÒ?ÇÚµåÆù ¹øÈ£ ¹Ù²Ù°í ½ÍÀºµ¥ ¾î¶»°Ô 
»õ·Î¿î ¹øÈ£¸¦ ´Ù ¾Ë¸®³ª °ÆÁ¤µÇ½Å´Ù±¸¿ä? µ¥ÀÌÄÞÀÇ "Æò»ý¹øÈ£ 
0505 ¼­ºñ½º"°¡ °£´ÜÈ÷ ÇØ°áÇØ µå¸³´Ï´Ù.ÀüÈ­¹øÈ£°¡ 
¹Ù²î¾îµµ, ÇÚµåÆù ¹øÈ£°¡ ¹Ù²î¾îµµ,¹Ù²ï 
¹øÈ£¸¸ °í°´´ÔÀÇ 0505¹øÈ£ ¾Æ·¡ µî·ÏÇØ µÎ¼¼¿ä.0505¹øÈ£´Â 
Æò~»ý ¹Ù²îÁö ¾Ê´Â ¹øÈ£À̱⿡ ÀÌ ¹øÈ£¸¸ ¾Ë·ÁÁÖ¸éÁÖÀ§ »ç¶÷µé°ú ¿¬¶ô ²÷¾îÁú ÀÏ 
Æò~»ý ¾ø½À´Ï´Ù.µ· µå´Â °Å ¾Æ´Ï³Ä°í¿ä? 
¿ÀÈ÷·Á µ· ¹ö´Â °Ì´Ï´Ù. °í°´´ÔÀÇ 0505¹øÈ£¸¦ 
¸¹ÀÌ ¾Ë¸®¼¼¿ä. ¾Ë¸° ¸¸Å­ 0505¹øÈ£·Î ÀüÈ­¸¦ 
¹ÞÀ¸½Ã¸é°¡ÀÔ ÈÄ 2³âµ¿¾È ÅëÈ­·áÀÇ 5%±îÁö 
µ¥ÀÌÄÞ ÀüÈ­¿ä±Ý¿¡¼­ ÇÒÀÎ ¹Þ°Å³ªÄ³½¬¹é 
º¸³Ê½ºÆ÷ÀÎÆ®·Î ´©ÀûÇÏ¿© ¹ÞÀ¸½Ç ¼ö ÀÖ½À´Ï´Ù. 
ÇÑÆí, °Å´Â »ç¶÷¿¡°Ôµµ ½Ã°£°ú ÀüÈ­ºñ¸¦ 
¾Æ²¸ÁÖ´Â ¼­ºñ½º¶ø´Ï´Ù. ³ª¸¦ Ư¡ÀûÀ¸·Î 
Ç¥ÇöÇØ ÁÙ ³ª¸¸ÀÇ ¹øÈ£¸¦ ã°í °è¼Ì³ª¿ä?ÀÌÁ¦ 
1,000¸¸°³ÀÇ ¹øÈ£ Áß¿¡¼­ ÀÚÀ¯·Ó°Ô ¼±ÅÃÇϽʽÿÀ. 
0505-3355-7770505-200-1004...µîµî ¾î¼­¾î¼­ ÁÁÀº 
¹øÈ£ È®º¸Çϼ¼¿ä. Áö±ÝÀÌ ÁÁÀº ±âȸÀÔ´Ï´Ù. 
Çà¿îÀÇ À̺¥Æ®¿¡ Âü°¡Çϼ¼¿ä. 4¿ù 30ÀϱîÁö 
0505¿¡ °¡ÀÔÇÏ°í, 5ȸÀÌ»ó ÀüÈ­¸¦ ¹ÞÀ¸½Å °í°´Áß 
 565ºÐ¿¡°Ô Ãß÷À» ÅëÇØ °æÇ°À» µå¸³´Ï´Ù. 
Âü, ¿ÃÇØ ¸»±îÁö´Â ¿ù 10ÅëÈ­ ¹Ì¸¸ ¹Þ¾Æµµ 
±âº»·áµµ ¸éÁ¦¶ø´Ï´Ù.  ÀÚ, ´ÔÀÇ 
¹øÈ£´Â ¸î ¹øÀ¸·Î ÇϽǷ¡¿ä? °ñ¶óº¸¼¼¿ä. 

http://www.urimaul.org/0505number/ 
(Ŭ¸¯!) 
º» 
E-mailÀº "Àü»ê¸Á º¸±ÞÈ®Àå°ú ÀÌ¿ëÃËÁø¿¡ 
°üÇÑ ¹ý·ü"¿¡ ÀÇ°ÅÇÏ¿© ¼ö½ÅÀÚ°¡ [¼ö½Å°ÅºÎ](Ŭ¸¯) Àǻ縦 
ȸ½ÅÀ¸·Î ¹àÈù ÈÄ¿¡´Â ¶Ç´Ù½Ã º¸³¾¼ö ¾ø½À´Ï´Ù. 
µû¶ó¼­ Çѹø¸¸ º¸³»µå¸²À» ¾È³»Çص帮¸ç, 
Ȥ½Ã º» E-mailÀ» ¹Þ°í ±âºÐÀÌ »óÇϼ̴ٸé 
¿ë¼­ÇϽʽÿÀ. ´Ù½Ã´Â º¸³»Áö ¾ÊÀ» °ÍÀÔ´Ï´Ù. 
¶ÇÇÑ °í°´´ÔÀÇ E-mailÀº °Ô½ÃÆÇÀ» ÅëÇØ 
¾Ë°Ô µÇ¾úÀ¸¸ç °í°´´ÔÀÇ E-mailÀ» Á¦¿ÜÇÑ 
°³ÀνŻóÁ¤º¸¿¡ ´ëÇؼ­´Â ÀüÇô ¾ËÁö ¸øÇÏ°í 
ÀÖ»ç¿À´Ï ¾È½ÉÇϽñ⠹ٶø´Ï´Ù.
 
 

Re: RFC: ./configure or ./config.status --clean

[Akim Demaille]

> "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.  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.

Re: RFC: ./configure or ./config.status --clean

[Akim Demaille]

> "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.status" would not necessarily work
Paul> on a different host, because config.status is host-specific and
Paul> knows only about files that it created.  In contrast,
Paul> "configure" is host-generic and knows about all files that could
Paul> possibly be created.

Nice point.

Paul> Being able to do a "make distclean" from any host is a nice
Paul> property, and it argues for doing things in "configure" rather
Paul> than in "config.status".

Actually, not really.  If you want to remove only what was created,
then you have to do it from config.status.  If you want to remove
everybody, you can from either.



>> * top level only?  Is distclean valid in a sub Makefile?

Paul> distclean is a standard GNU make target, so I would think every
Paul> sub Makefile should support it.

>> What is the semantics then?  Should it apply to the whole tree, or
>> just the subtree?

Paul> My kneejerk reaction is that a sub Makefile should clean the
Paul> files it builds, which are normally just the files in its
Paul> subtree.

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 will answer that ./config.status foo/Makefile
does it all, but...

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 reasonable to me.  The problem being the
last two words, of course :)




Paul> However, you're also saying that a 'Makefile' should not remove
Paul> itself with 'make distclean'.  I think this is a bit more
Paul> controversial, partly because of the common-sense principle
Paul> mentioned above, and partly because there will be a nontrivial
Paul> software conversion effort among Autoconf users who do not use
Paul> Automake.

I was probably confusing, because I was addressing two different
things:

1. I'm more interested in having a Makefile remove itself without
knowing than with removing itself explicitly.  I mean that the
Makefile should not try to learn what is built in its directory
(amongst which there is the Makefile itself).  The Makefile should ask
config.status what is to be removed.

2. Because `distclean' doesn't make a lot of sense to me in subdir, as
an additional question, do we still want to enable distclean from a
subdir, and if so, would it be grave that this subdir distclean
triggers the top level's distclean.

And, as far as Automake goes, I don't think I'm making things worse to
its non-users.  Nothing changes for them.


>> it makes make distclean more robust to interruption: until
>> ./config.status is really run, the Makefiles are still present.

Paul> That's a good point.  However, if ./config.status is interrupted
Paul> we would still have the problem.

Nope, as long as config.status is present, it is able to remove the
products.  And if we move this feature to configure, then it is even
valid if config.status has disappeared.



Paul> Can't we achieve this advantage in a better way?  Here's an
Paul> idea:

Paul>   Before "make distclean" descends into a subdirectory, it tests
Paul> whether that subdirectory has a Makefile, and skips the
Paul> subdirectory if the Makefile is missing.

I'm not sure to understand the framework you consider here.  I'm
interested in the Autoconf feature, and therefore, I don't care much
of what the Makefile itself does.  So, are you referring to
config.status --clean being invoked in a subdir?


Paul> If "rm Makefile" is the the last thing that "make distclean"
Paul> does, then this alternate proposal is more robust than the
Paul> method you proposed.  That is because "rm Makefile" is atomic.
Paul> So it wouldn't matter when you interrupted the "make distclean";
Paul> if there was more work to do, another "make distclean" would
Paul> still do it.

IIUC, you're saying config.status --clean should end with the top
level.  I agree.

Re: RFC: ./configure or ./config.status --clean

[Roger Leigh]

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 will answer that ./config.status foo/Makefile
> does it all, but...

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.

-- 
Roger Leigh
** Registration Number: 151826, http://counter.li.org **
Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers

Re: RFC: ./configure or ./config.status --clean

[Paul Eggert]

> 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
> does it all

You read my mind!  :-)

> but... It imposes quite some complications to maintain this possibility,

What complications are these?

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 the right thing to do, in the usual case where all
configuration is done at the top level.

I hope this removes the complications


> 1. I'm more interested in having a Makefile remove itself without
> knowing than with removing itself explicitly.  I mean that the
> Makefile should not try to learn what is built in its directory
> (amongst which there is the Makefile itself).  The Makefile should ask
> config.status what is to be removed.

That would be one way to do it.  But if it's done that way, the
Makefile should still be the last thing to be removed.

> do we still want to enable distclean from a subdir, and if so, would
> it be grave that this subdir distclean triggers the top level's
> distclean.

I think people will be surprised if doing it in a subdir does it for a
parent dir.  It would be better not to do it at all than to do too
much.

> Paul> That's a good point.  However, if ./config.status is interrupted
> Paul> we would still have the problem.
> 
> Nope, as long as config.status is present, it is able to remove the
> products.

But I was talking about the point of view of the person who types
"make distclean".  That person should be able to type "make distclean"
again, if the first one gets interrupted.  Therefore, if "make
distclean" invokes "config.status --clean" we have a problem.  Either
"config.status --clean" removes the Makefile last -- in which case
"config.status --clean" does not work properly if reinvoked after
being interrupted; or it removes config.status last -- in which case
"make distclean" does not work properly if reinvoked after being
interrupted.

Perhaps "make distclean" should invoke "./configure --clean", which
would take care to remove the Makefile last.  This avoids the problem
since "configure" is not removed.  But once we have "./configure
--clean", I don't see the point of having "./config.status --clean".
As far as I can see, anybody who wants to invoke the latter will
prefer invoking the former.  I don't think it _hurts_ to have
"config.status --clean", but I don't see why anybody would want to use
it.


> Paul>   Before "make distclean" descends into a subdirectory, it tests
> Paul> whether that subdirectory has a Makefile, and skips the
> Paul> subdirectory if the Makefile is missing.
> 
> I'm not sure to understand the framework you consider here.  I'm
> interested in the Autoconf feature, and therefore, I don't care much
> of what the Makefile itself does.  So, are you referring to
> config.status --clean being invoked in a subdir?

The latter.  I was referring to "make distclean" being invoked in a
directory with a subdirectory.  The directory might not be at the top
level.

> Paul> If "rm Makefile" is the the last thing that "make distclean"
> Paul> does, then this alternate proposal is more robust than the
> Paul> method you proposed.  That is because "rm Makefile" is atomic.
> Paul> So it wouldn't matter when you interrupted the "make distclean";
> Paul> if there was more work to do, another "make distclean" would
> Paul> still do it.
> 
> IIUC, you're saying config.status --clean should end with the top
> level.

I was thinking of "make distclean", not "config.status --clean",
though the principles are similar.  Also, I was thinking only of "make
distclean" at a particular level.  I wasn't thinking that "make
distclean" in a subdirectory would invoke "make distclean" in a
parent.

Re: RFC: ./configure or ./config.status --clean

[Eric Siegerman]

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 started
deleting stuff outside that tree.  I would be much less
surprised if it did nothing, especially if it printed a
nice message in the process:
`distclean' is not supported in subdirectories.  Please type:
cd ../../..; make distclean

  - Level of damage:  Suppose I type "make distclean" in a
low-level subdirectory of a package that takes a couple of
hours to build.  Suddenly I have a full rebuild on my hands,
as opposed to going to the top level and typing
"config.status", and perhaps having to wait for each Makefile
to redundantly regenerate itself (*if* that's still happening,
it's a pet peeve for another thread :-)


> I'm
> interested in the Autoconf feature, and therefore, I don't care much
> of what the Makefile itself does.

I'm not sure it's possible to think of them in isolation.  After
all, what's being discussed is probably the thorniest point of
interface between Autoconf and the build system (whether the
latter is Automake-generated or not) -- which is why the status
quo needs work in the first place...


> Paul> If "rm Makefile" is the the last thing that "make distclean"
> Paul> does, then this alternate proposal is more robust than the
> Paul> method you proposed.  That is because "rm Makefile" is atomic.
> Paul> So it wouldn't matter when you interrupted the "make distclean";
> Paul> if there was more work to do, another "make distclean" would
> Paul> still do it.
> 
> IIUC, you're saying config.status --clean should end with the top
> level.  I agree.

And, if asked to clean a subdirectory, should clean that
subdirectory's Makefile last.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
"Outlook not so good."  That magic 8-ball knows everything!
I'll ask about Exchange Server next.
- Anonymous

Re: RFC: ./configure or ./config.status --clean

[Eric Siegerman]

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 the right thing to do, in the usual case where all
> configuration is done at the top level.

Hey, that's cool!  Even if configuration is done at several
levels, this generalizes cleanly, I think:  in any directory with
a configure script (i.e. $top_builddir, plus any directory
referred to in the AC_CONFIG_SUBDIRS() tree), "make distclean"
cleans configure-time stuff; in any other directory, it just does
"make clean".

If a user types "make distclean" in an AC_CONFIG_SUBDIRS()
directory, they'll have to rerun configure, either in that
directory or back up at top_builddir.  That's still a bit
awkward, but better than the status quo, I think.

It does violate the PoLP (principle of least surprise) again,
though, to have distclean sometimes doing one thing and sometimes
another.


[N.B.: The rest of this message does not apply if the above
suggestion of Paul's is taken.  Doing so would complicate the
rule, but would also sidestep the problem.]


> But I was talking about the point of view of the person who types
> "make distclean".  That person should be able to type "make distclean"
> again, if the first one gets interrupted.

The rule should be:
A directory needs to have "make distclean" run in it
iff it contains a Makefile.

Thus:
  - Makefile should be the first file generated by config.status
(the AC_CONFIG_FILES() order should be shuffled accordingly
  - Makefile should be the last file deleted by "make distclean"

> Therefore, if "make
> distclean" invokes "config.status --clean" we have a problem.  Either
> "config.status --clean" removes the Makefile last -- in which case
> "config.status --clean" does not work properly if reinvoked after
> being interrupted; or it removes config.status last -- in which case
> "make distclean" does not work properly if reinvoked after being
> interrupted.

Yeah, in theory there's a race condition.  But if they're removed
last and second-last, in the same "rm" command, the likelihood of
being interrupted in *just* the wrong place is vanishingly small.
More of a problem, I suspect, is that the user can manually
remove a Makefile; that violates the rule, and there's not much
we can do about it.

I guess that's an argument for having the top-level
"config.status --distclean" clean the whole tree ... or for this:

> 
> Perhaps "make distclean" should invoke "./configure --clean", which
> would take care to remove the Makefile last.  This avoids the problem
> since "configure" is not removed.  But once we have "./configure
> --clean", I don't see the point of having "./config.status --clean".
> As far as I can see, anybody who wants to invoke the latter will
> prefer invoking the former.  I don't think it _hurts_ to have
> "config.status --clean", but I don't see why anybody would want to use
> it.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
"Outlook not so good."  That magic 8-ball knows everything!
I'll ask about Exchange Server next.
- Anonymous

Re: RFC: ./configure or ./config.status --clean

[Peter Eisentraut]

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 provide a list of files that you generate and then the
makefile author/generator can decide what to do with it.

After all, the problem really only affects a few temp files potentially
left over from configure or config.status.  All other files are already
accounted for.  Don't try to change everything.

-- 
Peter Eisentraut   [EMAIL PROTECTED]

Re: RFC: ./configure or ./config.status --clean

[Peter Eisentraut]

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 --clean?

-- 
Peter Eisentraut   [EMAIL PROTECTED]

Re: RFC: ./configure or ./config.status --clean

[Russ Allbery]

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 significantly over-solving this problem.
Just document somewhere what files can possibly be created and let the
package author do what they wish with them, write a make distclean rule or
whatever.  If Automake wants to include that stuff, they can read the
Autoconf documentation to see what to remove.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC: ./configure or ./config.status --clean

[Russ Allbery]

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 reasonable to me.  The problem being the
> last two words, of course :)

maintclean in a subdirectory is useful and fairly well-defined, however.
Think of removing bison-generated parsers.  And usually maintclean depends
on distclean, the way most makefiles that I've seen are written.

> 2. Because `distclean' doesn't make a lot of sense to me in subdir, as
> an additional question, do we still want to enable distclean from a
> subdir, and if so, would it be grave that this subdir distclean triggers
> the top level's distclean.

Running distclean in a subdirectory triggering the parent's distclean
target would indeed be a very grave bug.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC: ./configure or ./config.status --clean

[Russ Allbery]

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.  The ability to remove autoconf-generated files in a
subdirectory is still useful, at least to me.  Usually for things like
version-control operations or the like.

But I'm guessing I probably won't be able to use the new support anyway,
given the underlying assumptions, so it probably doesn't make a lot of
difference.  I just hope that the Autoconf documentation will describe the
files that could potentially be created for those of us who will still
need to write our own makefiles.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC: ./configure or ./config.status --clean

[Paul Eggert]

> 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)

Re: RFC: ./configure or ./config.status --clean

[Dan Kegel]

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 it stop?  gcc --clean?  ld --clean?  touch --clean?

Clearly, one would also want cp --clean.

- Dan