If AC_CONFIG_AUX_DIR is not used, and version.texi is in a doc
directory, than "automake -a" installs mdate-sh in top_srcdir, but the
Makefile.in in the doc directory tries to use mdate-sh in srcdir,
which mdate-sh does not exist.
One approach to a fix is to use mdate-sh in top_srcdir, and I incl
In automake-1.4f, in a directory using dejagnu, I ended up with a
if %
in the middle of Makefile.in
Here's a patch which fixes the problem:
--- automake-1.4f.orig/lib/am/dejagnu.am
+++ automake-1.4f/lib/am/dejagnu.am
@@ -74,7 +74,7 @@
## Note that in the rule we don't directly generate site.e
Hey, I have a question about the interpolation of automake variables like
pkglibdir, pkgdatadir, etc. Suppose your package installs programs and
scripts which need to know where to find your package's data files, and you
want your documentation to have the full paths of your program, etc.
The wa
> Besides the reason that it's not nessasary are there any reasons why
> the automake inference rules for C and C++ don't use -o ?
>
> I seem to remember that some compilers don't accept -o is this correct?
Yes. Some older compilers will not accept both -c and -o .
> If so what is the typical
Besides the reason that it's not nessasary are there any reasons why
the automake inference rules for C and C++ don't use -o ?
I seem to remember that some compilers don't accept -o is this correct?
If so what is the typical way of dealing with the lack of -o when
you want it?
PGP signature
On Sunday 03 June 2001 4:21 am, Robert Collins wrote:
>
> I figured that changing the call to libtool to use "foo" not "foo.exe"
> would be a bad thing in some cases... so I altered libtool to check for
> "foo" as a libtool program if it is given "foo.exe" but "foo.exe" does
> not exist. The patc
