Hi!
Akim told me awhile back to port forward and resubmit some patches if
I noticed that they hadn't been accepted after some time had passed.
Anyway, it's been awhile, so here's a resubmission of the patch that
fixes the stamp-h? processing which configure is currently doing.
Basically, the
Stephen Cameron wrote:
It's getting a bit weird now,
Making all in lib
source='argmatch.c' object='argmatch.o' libtool=no \
depfile='.deps/argmatch.Po' tmpdepfile='.deps/argmatch.TPo' \
depmode=none /bin/sh ../depcomp \
../compile cc -DHAVE_CONFIG_H -I. -I.
Sounds like this could be fixed in depcomp?
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
Very funny Scotty, now beam down my clothes!
Hi,
I'm Trying to update an old SCO
Akim Demaille wrote:
Tom == Tom Tromey [EMAIL PROTECTED] writes:
Tom We're planning to get rid of aclocal in the future. I forget
Tom exactly what form that plan takes. Akim knows.
First of all, the responsibility will move to Autoconf, aclocal has
nothing to do with Automake.
The
Jim Meyering wrote:
Hi Derek,
Recently, automake changed so that I get the following in fileutils-4.1,
even though I've put a copy of mdate-sh (though not in the official tarball)
in doc/.
$ automake --gnits --include-deps
doc/Makefile.am:2: required file `./mdate-sh' not found
I
Akim Demaille wrote:
"Robert" == Robert Collins [EMAIL PROTECTED] writes:
Robert The project I'm converting to automake uses
Robert AC_CONFIG_AUX_DIR(cfgaux). The dependency cehcking code was
Robert looking for depend in the srcdir, not the srcdir/cfgaux. I'm
Robert using a cvs version
Akim Demaille wrote:
"Tom" == Tom Tromey [EMAIL PROTECTED] writes:
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim elsif (/^\@(syncode|print)index \w+ (\w*)/) { push
Akim @clean_suffixes, "$1s";
Tom Shouldn't that be "$2s" here?
Yes, definitely. Thanks!
Neither one worked. I
Akim Demaille wrote:
elsif (/^\@syncodeindex \w+ (\w*)/
|| /^\@printindex (\w+)/)
{
push @clean_suffixes, "$1s";
}
Yep. That works.
IIRC, you also had problems with fns. What does a `grep fn *texi*' gives?
Not much obviously useful, but you
Tom Tromey wrote:
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Derek Is there some reason the automake test suite doesn't allow the
Derek user to override its AUTOMAKE ACLOCAL variables? I like to
Derek do it on ocassion to compare the current behavior against my
Derek
Tom Tromey wrote:
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Derek Is there some reason the automake test suite doesn't allow the
Derek user to override its AUTOMAKE ACLOCAL variables?
Thanks for the patch. I wrote a ChangeLog entry for you. Could you
write it next
:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
Boy: A noise with dirt on it
Derek R. Price writes:
* depcomp: Don't count on $? being set in then or else clauses.
What system is this happening on? depcomp is part of the Automake
distribution.
Boy, that was fast! I
Akim Demaille wrote:
| Akim Demaille wrote:
|
| Could you `grep indexcode' your texi sources? Thanks!
|
| [dprice@empress doc]$ fgrep indexcode cvs.texinfo
| [dprice@empress doc]$
Actually I meant _all_ your sources. And in fact, @include would be
useful too.
Sorry for the
Akim Demaille wrote:
Tom Tromey [EMAIL PROTECTED] writes:
What remains in order to enable `use strict'?
[. . .]
$require_file_found{'depcomp'} = 1 if -f "$depcomp_dir/depcomp";
it is because of this guy. It should not be used directly here, but
to fix this properly, I have
Building postscript docs from *.texi sources using the default automake
targets, the dev version of CVS produces cvs.cps cvs.fns files as side
effects. These files aren't removed by 'make clean' and thus break a
distcheck.
Derek
--
Derek Price CVS Solutions Architect (
Akim Demaille wrote:
hi Derek,
Hi. :)
Could you `grep indexcode' your texi sources? Thanks!
[dprice@empress doc]$ fgrep indexcode cvs.texinfo
[dprice@empress doc]$
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED]
Alexandre Oliva wrote:
On Feb 28, 2001, "Derek R. Price" [EMAIL PROTECTED] wrote:
CVS uses a single second sleep to guarentee timestamps change cross-platform
IIRC, FAT filesystems can only store even second numbers. So, in
order to be 100% safe, you'd need to sleep for
Akim Demaille wrote:
# Now do all the work on each file.
foreach my $am_file (@input_files)
{
if (! -f ($am_file . '.am'))
{
am_error ("\`" . $am_file . ".am' does not exist");
}
else
{
generate_makefile ($output_files{$am_file}, $am_file);
}
}
Akim Demaille wrote:
"Derek R. Price" [EMAIL PROTECTED] writes:
Only a global is going to be seen within a separate function...
Right, but `my' at the top level is a global. The problem was really
related to the specific semantics of foreach.
Huh. You're right. I didn't b
Pavel Roskin wrote:
Some unices (including GNU/Linux) are not very precise with respect to the
timestamps. It's likely that parse.c and the new parse.y are created in
the same second, so parse.c will appear to be up-to-date. Adding "sleep
3" (I have no idea what would be a minimal safe
Tom Tromey wrote:
"Akim" == akim [EMAIL PROTECTED] writes:
Akim I wonder why we have a hard coded list list this in subdirs.am:
Akim [ ... -recursive targets ... ]
Historical reasons only, ie, I never thought of it.
Akim Not only to I find this more pleasant, but most importantly it's
Tom Tromey wrote:
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim Six, six for them! (I'm not counting those for file handles,
Akim which perl refuses as my, not sure to understand why).
The way file handles work is another reason to dislike Perl. At
least, I've always found them
Tom Tromey wrote:
if FOO
var = a b
endif
derived = $(var:%=%.c)
if BAR
var = c d
endif
Isn't the order irrelevant here since derived won't be evaluated until
it's used?
Um, the gmake manual calls this "expanded when read, except for the shell
commands in
From tests/defs:
# User can set which tools from Autoconf to use.
test -z "$AUTOCONF" AUTOCONF=autoconf
if ($AUTOCONF --version) /dev/null 21; then
has_autoconf=:
needs_autoconf=:
else
has_autoconf=false
needs_autoconf='exit 77'
fi
What's
"Derek R. Price" wrote:
AUTOCONF='exit 77 '
Excuse me:
AUTOCONF='exit 77 dummy'
to keep the parser eternally happy.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com
"Derek R. Price" wrote:
"Derek R. Price" wrote:
AUTOCONF='exit 77 '
Excuse me:
AUTOCONF='exit 77 dummy'
to keep the parser eternally happy.
Or almost eternally happy. Due to some wierdness where my Bash only evaluates a
variable as a single co
"Derek R. Price" wrote:
test='eval exit 77 dummy'
Whoops. Excuse me. That works in every case except ($test). The subshell created
by parens breaks things. I guess that isn't all that robust.
Derek
--
Derek Price CVS Solutions Architect ( http://C
Akim Demaille wrote:
Pavel Roskin [EMAIL PROTECTED] writes:
We probably need a special macro, e.g. AC_REQUIRE_FILE, so that the
macros will be able to indicate what files they need.
This is what Derek and I are working on :) But I doubt 2.50 will be
the good starting point, 2.51 will.
Is there a good reason that the following constructs occasionally appear
in 'configure.in's as created by the test suite?
AM_INIT_AUTOMAKE(nonesuch, nonesuch)
PACKAGE=nonesuch
VERSION=nonesuch
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
Akim Demaille wrote:
What is the general policy wrt `optimizations' in automake vs leaving
some job to make? For instance there are many places with code like:
if ($relative_dir eq '.')
{
push (@files, 'acconfig.h');
}
Tim Van Holder wrote:
* remake-hdr.am (@STAMP@): Use .T as suffix for the
temporary file.
You should probably patch autoconf's autoreconf too.
What part would need patching?
The one that choose stamp file names like those created by automake.
Right - I hadn't noticed
Tom Tromey wrote:
"Tim" == Tim Van Holder [EMAIL PROTECTED] writes:
Tim 2001-02-10 Tim Van Holder [EMAIL PROTECTED]
Tim* remake-hdr.am (@STAMP@): Use .T as suffix for the
Timtemporary file.
I don't think this is sufficient. I think you also have to change
AM_CONFIG_HEADER as
Is there a good reason that Automake renames the three variables set by
AC_CANONICAL_* ('build', 'host', 'target') to 'build_triplet', 'host_triplet',
'target_triplet'?
Because using the current traces design, 'build', 'host', 'target' would be
substituted automatically, allowing
I've removed the references to $seen_canonical, re one of the FIXME
comments on the way to enabling traces. I know this patch is kinda
largish, but even if it doesn't get checked in yet, I'd like some
feedback. This is somewhat integral to my work on traces.
Derek
--
Derek Price
"Derek R. Price" wrote:
"Derek R. Price" wrote:
Looks like someone broke the 'make dist' target in the last few days.
Specifically, input files from AC_OUTPUT are no longer being added to
DIST_COMMON...
Here's the patch.
This doesn't appear to be the correct fix.
Tom Tromey wrote:
Anyway I wrote a test for the weird case and checked it in.
I also checked in a fix for both the recent bugs in that area. I'm
afraid I'm not entirely sure why my fix fixes distcommon.test :-(.
Checked in? Fixes? I'm not pulling any changes...
Derek
--
Derek Price
Tom Tromey wrote:
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
I'm checking this in.
Pavel I'm sorry, but the bug seems to be yours. The new test fails
Pavel after automake.in changes from revision 1.848 to 1.849.
Oh, I know it is mine..
Pavel In fact it says directly: "Don't
"Derek R. Price" wrote:
Tom Tromey wrote:
Derek Checked in? Fixes? I'm not pulling any changes...
I can't explain that. I've seen the commit message and everything.
You aren't using the subversions automake are you?
That is a mirror that doesn't update.
Yeah, I
Pavel Roskin wrote:
On 7 Feb 2001, Tom Tromey wrote:
I've long considered it a mistake that tests/ChangeLog exists. I
think it should be merged with the main ChangeLog.
How about I rename tests/ChangeLog and we start putting entries into
the toplevel ChangeLog? Any objections?
No
Tom Tromey wrote:
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Derek Also, looking at this area of the code reminds me that I sent
Derek a, unfortunately largish, patch in something over a month ago
Derek that hasn't been reviewed to my knowledge. The patch was
Dere
Tom Tromey wrote:
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Derek Also, looking at this area of the code reminds me that I sent
Derek a, unfortunately largish, patch in something over a month ago
Derek that hasn't been reviewed to my knowledge. The patch was
Dere
Inspired by Akim Demaille's use of ifdef, I wrote a third edition of
this patch which increases functionality when used with a current
Autoconf.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue (
"Derek R. Price" wrote:
Inspired by Akim Demaille's use of ifdef, I wrote a third edition of
this patch which increases functionality when used with a current
Autoconf.
I just wanted to let you all know that.
...
Ok, fine, here's the patch. :)
Derek
--
D
Somebody checked in a bad quote recently. It breaks at least the
stamph/header targets. Patch attached.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
82. Hold a hard drive to your
Akim Demaille wrote:
"Derek R. Price" [EMAIL PROTECTED] writes:
All these comments are related to the same idea: Automake must know as
less as possible about macros. It means that if needed, we have to
~/src/ace % echo "AC_INIT AC_CANONICAL_SYSTEM" | ace -t AC
Akim Demaille wrote:
FYI, I applied this to Autoconf:
2001-02-03 Akim Demaille [EMAIL PROTECTED]
* acfunctions.m4 (AC_FUNC_ERROR_AT_LINE, AC_FUNC_ONSTACK): Use
AC_LIBSOURCES.
2001-02-03 Akim Demaille [EMAIL PROTECTED]
* acgeneral.m4 (AC_LIBOBJ_DECL): Remove.
[EMAIL PROTECTED] wrote:
On Fri, Feb 02, 2001 at 01:17:13PM -0500, Derek R. Price wrote:
Akim Demaille wrote:
"Derek R. Price" [EMAIL PROTECTED] writes:
Patch against the current CVS Automake attached. Please excuse all the
"print STDERR"s and my initials
"Derek R. Price" wrote:
[EMAIL PROTECTED] wrote:
On Fri, Feb 02, 2001 at 01:17:13PM -0500, Derek R. Price wrote:
Akim Demaille wrote:
that I certainly would like to toy with your implementation, I'd vote
for an inclusion in Automake. Do you have your papers? :)
No, ac
stamp-h? files in subdirs are still being created in the wrong locations
by an automake configure script. The problem was in AM_CONFIG_HEADERS.
I fixed it, but is dependent on the autoconf beta. Patch attached.
I was thinking of attempting to eliminate the need for the recreation of
stamp-h?
The amtraces functionality for AC_CONFIG_FILES is totally broken.
Anyone mind if I spend a few minutes on it?
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
I don't suffer from stress.
Tim Van Holder wrote:
(_AM_DIRNAME): helper function which basically implements an sh
`dirname` in m4
Only have 1 problem with it: no support for DOS-style paths (and this is
conveniently not tested in your dirname.test either :-P).
Yeah, sorry. I noticed that, but I
Why do automake stamp targets go through all the trouble of creating a
temporary stamp file before executing config.status and then moving the
stamp file into the correct position?
thirdfile.h: stamp-h3
@if test ! -f $@; then \
rm -f stamp-h3; \
Harlan Stenn wrote:
Are there several issues here?
The package maintainer has the package to worry about.
Aha! Here's the crossed wire. What I was envisioning was a package tool
designed such that most platforms wouldn't _need_ devoted package maintainers.
A single package maintainer using
Tom Tromey wrote:
Unfortunately, I don't think it is that easy.
First, Makefile.am contents can be conditional on the particular
configuration. That is why you really want to deal with the
post-configuration package (using `make') and not Makefile.am.
Second, the more complex
It seems some BSD makes don't look through VPATH for targets either
(i.e. when they're not found in $(builddir) make assumes they are
missing and rebuilds).
Mostly this isn't a problem, but there are a few cases where it is. For
example, info targets are rebuilt every time and I can't create a
Tom Tromey wrote:
The idea behind DOCUMENTATION is to provide a way to install README
and the other stuff that ends up (eg) in /usr/doc/$PACKAGE.
Just a note, I believe the RedHat standard is /usr/share/doc now.
Derek
--
Derek Price CVS Solutions Architect (
Found another bug in automake's support for dependencies using BSD's make. This
one is based on the fact that BSD make doesn't allow comments to continue on the
next line using '\'. I just hooked into the existing conditional machinery
instead of stuffing "\@AMDEP\@" as the first item in the
Whoops. Missed a list.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
He who laughs last thinks slowest.
Harlan Stenn wrote:
/bin/sh: BA: not found
WARNING: `:' is needed,
Tom Tromey wrote:
I wouldn't be averse to adding a `pdf' target so that `make pdf' works
as expected. Someone else would have to write it though since I don't
know how.
It should be the exact target used for DVI except for the addition of a
'--pdf' switch to the texi2dvi command line. I'm
Raja R Harinath wrote:
BTW, why do you need to 'configure' or 'sed' substitute a version
number into a .c file -- you already have config.h which defines the
symbol 'VERSION' to the version number string.
That's a good point. They're there because I just converted this source to use
"Derek R. Price" wrote:
Raja R Harinath wrote:
BTW, why do you need to 'configure' or 'sed' substitute a version
number into a .c file -- you already have config.h which defines the
symbol 'VERSION' to the version number string.
That's a good point. They're there beca
Tom Tromey wrote:Derek Apparently BSD wants something like the following:
Derek .include "file"
Derek or
Derek .include file
Yuck. Does make have -I options too?
Don't know. I didn't actually have a BSD box until last week and I haven't
touched it over the last few days. I'll
Tom Tromey wrote:
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Hmm. I'm running RH 6.2 and /usr/bin/etags is the GNU version:
I just looked into it and it looks like etags was distributed with the
version of emacs (20.5) that was distributed with RedHat 6.2. They've
remov
The distclean-generic target is removing the following files:
stamp-h stamp-h[0-9]*
The listing of 'stamp-h[0-9]*' causes 'stamp-h[0-9].in' files to be
removed incorrectly.
And incidentally, it would be unecessary to list stamp-h if you applied
the stamp-h fix I sent to the list sometime
I have several files which are generated by configure that I want three
things to happen to.
1) Created in $(srcdir) rather than $(builddir) or, alternately and
second best, targets added which make the $(srcdir) counterparts
dependent on the $(builddir) versions. I don't like option 2 because
Is there any support in Automake for BSD make's style of includes?
Apparently BSD wants something like the following:
.include file
or
.include file
Where and have similiar meanings to what they would have in a C
program include.
Derek
--
Derek Price CVS
Tom Tromey wrote:
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Derek Is there a good reason the configure script creates
Derek $(top_builddir)/.deps during the test that sets $DEPDIR and
Derek doesn't delete it again? Besides some developer or other
Derek needing sleep?
vtexi.test is failing in the CVS automake. I assume it broke due to the
recent vtexi behavior change.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
[Let us] go on in doing with [the]
I added the etags support to my RPMs:
http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_5.src.rpm
http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_5.src.rpm
Derek
--
Derek Price CVS Solutions Architect (
http://CVSHome.org )
mailto:[EMAIL
"Derek R. Price" wrote:
vtexi.test is failing in the CVS automake. I assume it broke due to the
recent vtexi behavior change.
I just looked and I was right. The fix was simple - the test simply wasn't
expecting the $(srcdir)/ prefix on version.texi.
Derek
--
D
Raja R Harinath wrote:
I added a macro to test for the presence of etags and whether it
supports "--etags-include=file" or "-i file" for includes.
If Exuberent etags is supposed to be a drop-in replacement for Emacs
etags, it should support the same options. Otherwise, it is a bug in
"Derek R. Price" wrote:
"Derek R. Price" wrote:
I added the etags support to my RPMs:
I regenerated them again using todays version of the CVS Automake since the
failing vtexi.test wasn't a bug.
And one more try. etags.m4 wasn't being installed re my recent email.
Re
Raja R Harinath wrote:
directory from the same source files, this would disable either the building
of PDFs or it would disable everything else.
Actually, new versions of texinfo.tex from ftp.gnu.org seem to not
need a special pdftexinfo.tex.
Yep. That seems to have done the trick as
Sebastian Rahtz wrote:
[EMAIL PROTECTED] writes:
Assuming I have a texinfo.tex a pdftexinfo.tex, both in '.', is there
some command that will allow 'texi2dvi foo.texi' and 'texi2dvi --pdf
foo.texi' to each find the appropriate texinfo.tex?
surely the simpler answer is to put
There was a bug in m4/header.m4 (AM_CONFIG_HEADER) which was causing
configure config.status to create a $(top_builddir)/stamp-h file for
every header file instead of the $(top_builddir)/$(subdir)/stamp-h$index
file it was supposed to create. Basically, a few shell metachars which
were supposed
Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
He who laughs last thinks slowest.
"Derek R. Price" wrote:
I built RPMs out of the CVS automake and with my fix for the depcomp
behavior. I figured I'd post them in case anybody
the Constitution called them to the
decision by suffrage, they pronounced their verdict, honorable to those who had
served them and consolatory to the friend of man who believes he may be
intrusted with his own affairs.
- Thomas Jefferson; 2nd Inaugural Address, 1805
"Derek R.
"Derek R. Price" wrote:
2) In the case of $config_aux_dir, I removed all the switches on '.' and '' and
replaced three with a switch on a new variable $config_aux_dir_set_in_configure_in
(yeah, I know that's a little long, but it sure is easy to interpret) which is
The CVS automake, using --add-missing and not using AC_CONFIG_AUX_DIR,
is placing depcomp in whatever directory it first encounters C files in
then looking for it during configure in $(top_srcdir).
The problem appears to start on line 3054 of automake.in (in the
handle_dependencies function):
)
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
82. Hold a hard drive to your ear -- listen to the C.
Raja R Harinath wrote:
"Derek R. Price" [EMAIL PROTECTED] writes:
The problem appears to start on line 3054 of automake.in (in the
handle_dependencie
is there some easy (i.e. not involving hacking) way to define a new
recursive target? e.g.:
RECURSIVE_TARGETS = remotecheck
which would shove remotecheck-recursive into the list with generated
targets all-recursive, check-recursive, install-recursive, etc. and add
a remotecheck
( http://OpenAvenue.com )
--
... one of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination of their C
programs.
- Robert Firth
Hi,
"Derek R. Price" [EMAIL PROTECTED] writes:
Alexandre Oliva wrote:
I'm in the middle of an attempt to convert CVS to use automake but I'm
having some trouble. Is there some way to selectively override clean
targets created by default for info targets without having to specify
the entire clean target manually?
I specified
info_TEXINFOS = cvs.texinfo
Okay, is there some way short of symlinking the
/usr/share/automake/texinfo.tex file by hand to make sure that automake
--add-missing uses the "proper" texinfo.tex file (i.e. the one installed
with the texinfo package and assumedly the most recent one)?
Derek
--
Derek Price
"Derek R. Price" wrote:
Why does AM require that texinfo.tex be included in the distribution in
the first place? It is installed with tex distributions by default
anyhow, isn't it? Its presence screws up my PDF target, which needs to
Okay, I found the no-texinfo.tex option
...
- Bart Simpson on chalkboard, _The Simpsons_
"Derek R. Price" wrote:
Automake seems to be creating targets by default that make use of
automake whether or not the user has automake installed. Timestamps
seem to get fouled up in distribution often enough that I think this is
Akim Demaille wrote:
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Derek This could be a very useful tool but without this feature I
Derek cannot use it in good conscience.
What's wrong with the `missing' approach? What version of Automake
are you using? I'm using CV
Paul Berrevoets wrote:
This should already be taken care of by the macro AM_MAINTAINER_MODE. If you use:
./configure --enable-maintainer-mode
then the autoconf/automake targets are enabled. They should be disabled by default.
Doesn't it make more sense to enable/disable the targets based
Akim Demaille wrote:
What's wrong with the `missing' approach? What version of Automake
are you using? I'm using CVS Automake for my package, and never found
such problem.
Oh, Version 1.4. And what's 'CVS Automake' as opposed to automake?
Derek
--
Derek Price CVS
Akim Demaille wrote:
What's wrong with the `missing' approach?
I ran automake the first time without the '--add-missing' argument so
when it told me it wouldn't run because "AUTHORS" and "missing" weren't
present I simply touched the files in expectation of figuring out what
GNU wanted of me
Is there some reason that *-local targets aren't always valid when their
parent exists? I wanted to define distclean-hdr-local to remove
options.h-SAVED as well as options.h, but I can't seem to get it to
work.
Derek
--
Derek Price CVS Solutions Architect (
90 matches
Mail list logo
