ir)/java
JAVA_FILES = MyClass1.java
if WITH_JDK
noinst_JAVA = $(JAVA_FILES)
endif
EXTRA_DIST = $(JAVA_FILES)
END
cat >MyClass1.java <<'EOF'
public class MyClass1
{
}
EOF
mkdir java
$ACLOCAL
$AUTOCONF
$AUTOMAKE
./configure GCJ=gcj
$MAKE
Braden> If the JAVAROOT definition is
> Oops. That was maintclean.test Oh, but I had
Bernd> autoconf-2.52 - re-running 'make check' now.
Bernd> (TESTS=maintclean.test PASSes against 2.53a)
Thanks a lot. I'm checking in the following patch.
2002-06-11 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
AC_CONFIG_FILES.)
If you prefer to use AC_SUBST_FILE, you should say `@mkfile@' in
your Makefile.am, not `include @mkfile@' as you initially wrote.
HTH
--
Alexandre Duret-Lutz
t with no source file
Braden> arguments.
Could you try this patch?
Index: ChangeLog
--- ChangeLog
+++ ChangeLog
@@ -1,1 +1,9 @@
+2002-06-11 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
+
+ * lib/am/java.am (class%DIR%.stamp): Don't run $(JAVAC) when there
+ is no
removing `-o g.lo' is not an option because then we don't
control where the object is created (if an object is created) and
we might overwrite something by mistake.
Tom, what do you think? I always feel apprehensive when changing depcomp.
2002-06-11 Alexandre Duret-Lutz <[EMAIL
; autoconf, not automake. So, any idea what might be triggering this?
I don't know. Indeed, CVS HEAD has a few changes in the
AM_CONFIG_HEADER/AC_CONFIG_HEADERS handling.
--
Alexandre Duret-Lutz
BRARIES = @LIBFOO2@
endif
and add
AC_SUBST([LIBFOO1], [libfoo.la])
AC_SUBST([LIBFOO2], [libfoo.la])
to your configure.ac.
--
Alexandre Duret-Lutz
autoreconf.
Ralf> I don't know anything about shtool.
Ralf> Whould you mind to explain, what it is and why automake
Ralf> should adopt it?
It might be better to discuss this here on [EMAIL PROTECTED]
--
Alexandre Duret-Lutz
We're pleased to announce the release of Automake 1.6.2
This is a bug fix release, and as such there is no new
features since Automake 1.6.1. The NEWS entry is appended.
You can find the new release here:
ftp://ftp.gnu.org/gnu/automake/automake-1.6.2.tar.gz
ftp://ftp.gnu.org/gnu/automak
rlan> specification.
Yep, Automake always assumes that the second argument
(global-vars.mk) is the template it must creates.
This sucks. Maybe it should check each argument until
it finds a `.am' for it.
Harlan> Suggestions?
AC_SUBST_FILE ?
--
Alexandre Duret-Lutz
libmsn_a_CFLAGS = $(AM_CFLAGS)
here.
| else
|
| st =
| pkg_LTLIBRARIES = libmsn.la
| noinst_LIBRARIES =
|
| libmsn_la_SOURCES = msn.c history.c
|
| endif
--
Alexandre Duret-Lutz
eep the libtool
Harlan> installation independent of any installed versions of
Harlan> automake.
There is also the following patch flying around for this. What
do you think of it?
http://mail.gnu.org/pipermail/automake-patches/2002-May/000787.html
[...]
--
Alexandre Duret-Lutz
nam. So it doesn't
make much sense documenting them.
[...]
Eric> Because right now I either have to split them out into
Eric> their own tiny package, or hack them myself to make them
Eric> versioned. Any ideas?
What about renaming the info files from the old versions?
--
Alexandre Duret-Lutz
On Fri, Jun 14, 2002 at 01:25:37PM -0400, Eric Dorland wrote:
>
> Well is automake 1.7 special in some way?
No. (At least CVS Automake insn't.)
> Or will it have versioned binaries as well?
It will, of course.
--
Alexandre Duret-Lutz
?!
Please show us config.log
--
Alexandre Duret-Lutz
Patrik> I inspected the Makefile.in and the Makefile itself.
Patrik> It does this:
Patrik> Makefile.in:
Patrik> @ENABLE_MYSQL_TRUE@libdir = $(LIBDIR)/programname
Patrik> libdir = @libdir@
I'm confused, are you showing the line from *each* Makefile.in
or from only one? In the latter case, that's clearly an Automake bug.
[...]
--
Alexandre Duret-Lutz
tories will be
David> using gcc. How do I acheive this using Automake?
You can override the CC or COMPILE variables in this
Makefile.am.
[...]
--
Alexandre Duret-Lutz
cdir, when it is really in the builddir.
Maybe &rewrite_inputs_into_dependencies could be taught that
when a file appears in @other_input_files it should be prefixed
with $(top_builddir) instead of $(top_srcdir)?
--
Alexandre Duret-Lutz
>>> "Marco" == Marco Kuhlmann <[EMAIL PROTECTED]> writes:
[...]
Marco> man_MANS = $(patsubst %.pod,%.3,$(pod_files))
Automake won't understand this.
Try
man_MANS = $(pod_files:.pod=.3)
Marco> %.3: %.pod
.pod.3:
--
Alexandre Duret-Lutz
x27; comes handy when the source layout matches the
installation layout:
nobase_pkgdatadir_DATA = templates/file1 templates/file2 ...
will install templates/file1 and templates/file2 as
$(pkgdatadir)/templates/file1 and $(pkgdatadir)/templates/file2.
[...]
--
Alexandre Duret-Lutz
[ -f $src -o -d $src ]
Clint> This is not strictly POSIX-conformant.
Damn! Are they removing things between revisions?
Clint> The line
Clint> if [ -f $src ] || [ -d $src ]
Clint> is compliant and might be more portable.
--
Alexandre Duret-Lutz
roblem is that I must list EACH file seperately.
Enrico> It will not let me just say include because it gives me
Enrico> an error message saying its a directory.
Enrico> Is there some other way I can have my header files installed?
No. Unless you write your own install-data-local.
--
Alexandre Duret-Lutz
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>> From: Alexandre Duret-Lutz <[EMAIL PROTECTED]>
>> Date: Wed, 26 Jun 2002 18:44:45 +0200
Clint> if [ -f $src -o -d $src ]
Clint> This is not strictly POSIX-conformant.
>>
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
[...]
adl> What Clint suggests (and your patch does) is to never use `-a'
adl> or `-o' *alone*; this makes quite a difference to me. It would
adl> be worth to document this if this rea
Hi!
>>> "Grzegorz" == Grzegorz Jakacki <[EMAIL PROTECTED]> writes:
[...]
Grzegorz> automake: Makefile.am: object `foo.$(OBJEXT)' created both with
Grzegorz> libtool and without
Follow the links.
http://sources.redhat.com/ml/automake/2002-06/msg00123.html
[...]
--
Alexandre Duret-Lutz
their own
unchecked directories, this restriction doesn't make much sense.
Removing this constraint would also cleanup the Automake code
(each primary has to supply a list of allowed standard
directories).
--
Alexandre Duret-Lutz
ners of this package for intructions
regarding compilation from CVS. (The usual way to add these
missing files is to run `automake --add-missing'.)
--
Alexandre Duret-Lutz
>>> "Jens" == Jens Krüger <[EMAIL PROTECTED]> writes:
Jens> Hi,
Jens> how can I add my test scripts add to the distribution
Jens> without typing it two times (in TESTS and
Jens> EXTRA_DIST). I'm using automake 1.6.1.
TESTS = foo
EXTRA_DIST = $(TESTS)
--
Alexandre Duret-Lutz
>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>>>>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> I tend to agree. Given that users can define their own
adl> unchecked directories, this restriction
and wanted to 'raise the
Chuck> alarm'...
Thanks, I'll fix this.
[...]
--
Alexandre Duret-Lutz
w.gnu.org/manual/automake/html_node/automake_12.html#SEC12
--
Alexandre Duret-Lutz
= $(SRCS)
[...]
Grzegorz> I do not understand why. Is this a bug?
Yes. Automake 1.6 and 1.6.1 have a bug when several sources
variables are defined from the same variable like you do.
This is fixed in Automake 1.6.2.
[...]
--
Alexandre Duret-Lutz
t; -Wl,--rpath causing the linking to fail.
Enrico> How might I fix this problem?
No idea. The libtool mailing list is <[EMAIL PROTECTED]>.
--
Alexandre Duret-Lutz
le.am that have only SUBDIRS. I
Jean-Eric> need to do something else than that (a custom
Jean-Eric> script), How do I write that in the Makefile.am?
I'm not sure I understand the question. I think you're seeking
for the `all-local' target.
--
Alexandre Duret-Lutz
w> templates in /usr/share/automake-1.6?
No, because if you do so other people will not be able to
rebuild the Makefiles of your package.
You could put these rules in a file (say `Makefile.rules'), that
you distribute with each project and `include' in each Makefile.am.
[...]
--
Alexandre Duret-Lutz
27;`; do?!)
It changes `foo/bar' into `pbar'.
Patrick> - or obsolete:
Patrick> === Running test ./obsolete.test
Patrick> .: obs.1: not found
Patrick> FAIL: obsolete.test
Could you show us the result of the following command?
env TESTS='gnits2.test gnits3.test obsolete.test' VERBOSE=x make -e check
[...]
--
Alexandre Duret-Lutz
failures.
The gnits2 and gnits3 failures show a difference between GNU
make and BSD make when run with the `-k' option: GNU make will
reflect whether it encountered an error in it's exit status
while BSD make will always succeed. I've submitted a separate
patch to documen
>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>>>>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> The gnits2 and gnits3 failures show a difference between GNU
adl> make and BSD make when run with the `
; which doesn't compile on a different box (assumes
mcmahill> particular headers).
I don't know. Why don't you install a portable yacc on your
development box? (e.g., bison)
This way you'll distribute portable code and will not require
your users to install yacc in order to compile your project.
--
Alexandre Duret-Lutz
ing patch on HEAD and
branch-1-6.
I think this was the last remaining failure on NetBSD, wasn't it?
2002-07-25 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* automake.in (read_am_file): Escaped newlines in comments are not
portable. If a comment line doesn't sta
We're pleased to announce the release of Automake 1.4-p6.
* This is NOT a bug fix release. *
* This is NOT the latest release of Automake. *
* This version we recommend you use is Automake 1.6.3. *
***
We're pleased to announce the release of Automake 1.6.3
This is a bug fix release, and as such there is no new
features since Automake 1.6.2. The NEWS entry is appended.
This will probably be the last release on the 1.6.x branch.
You can find the new release here:
ftp://ftp.gnu.org/gnu/aut
On Sat, Jul 27, 2002 at 11:58:05AM -0700, Bruce Korb wrote:
> Makefile.am:
> > distcleancheck_listfiles = \
> > find -type f -exec sh -c 'test -f $(scrdir)/{} || echo {}'
The -exec argument should be terminated by \;
You wrote $(scrdir) instead of $(srcdir).
--
Alexandre Duret-Lutz
Here is a snapshot of the current development version of Automake,
in case you want to get a grasp of what Automake 1.7 will look like.
The NEWS entry is appended.
If you have some time, please try it on your package and report any
issue you encounter. Especially, please shout loud if your packa
>>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
[...]
Robert> This means:
Robert> build dist tree
Robert> compress with compressor 1
Robert> compress with compressor 2
Robert> clean dist tree
This is the current behavior of `make dist'.
[...]
--
Alexandre Duret-Lutz
ist dist-all: dist-bzip2'?)
--
Alexandre Duret-Lutz
cause nobody has ever asked for such a feature.
--
Alexandre Duret-Lutz
>>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> On Tue, 2002-07-30 at 19:02, Alexandre Duret-Lutz wrote:
>> >>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
>>
>> [...]
>>
.0.0.0
| gcc: FiniteStateMachine.lo: No such file or directory
| gcc: FSMAction.lo: No such file or directory
Which version of libtool are you using?
--
Alexandre Duret-Lutz
I still
Waldemar> don't have neither .a nor .so file, but this is
Waldemar> another problem, isn't it?
I think building C++ libraries with libtool 1.4.x is tricky, but
I'm not the one to ask.
--
Alexandre Duret-Lutz
except when it looks like -pMINOR[ALPHA]: some versions
# were labelled like 1.4-p3a, this is the same as an alpha release
# labelled 1.4.3a. Yes it's horrible, but Automake did not support
# two-dot versions in the past.
--
Alexandre Duret-Lutz
Hi!
>>> "Ladislav" == Ladislav Strojil <[EMAIL PROTECTED]> writes:
[...]
Ladislav> I am trying to move our school project to automake.
What version of Automake?
[...]
--
Alexandre Duret-Lutz
the output
John> files for *.l should be named *.cc ?
I don't think you can. However if you name your lexer `foo.ll'
then Automake will build `foo.cc'.
--
Alexandre Duret-Lutz
n your Makefile.am and
the resulting Makefile.in?
[...]
--
Alexandre Duret-Lutz
hat contains
comparison functions which are able to cope with most version
numbering schemes. Reuse this work! This way it will solve
your problem, not only for Automake, but also for many other
tools at the same time.
[...]
--
Alexandre Duret-Lutz
Bob> it's committed :)
CVS Automake needs Autoconf 2.53b. So we can't release 1.7 before
2.54 is released. AFAICT that's the only point holding up the release.
--
Alexandre Duret-Lutz
v> configure.in:6: error: possibly undefined macro: AC_PROG_LIBTOOL
That's unrelated to Autoconf. You probably installed Automake
1.6.3 in a different location than Automake 1.5 was.
You need to install Libtool and Automake with the same --prefix
for the above command line to work.
[...]
--
Alexandre Duret-Lutz
'
[...]
Thanks. I can reproduce this, it's definitely a bug in
Automake. It seems Automake outputs these rules twice because
it has seen two differents C++ extensions (.cc and .cpp). I'll
look into this.
As a workaround you can rename your files to use only one of
these extensions (yep, this sucks).
--
Alexandre Duret-Lutz
c and .cpp). I'll
>> look into this.
Actually I'm able to reproduce it with Automake 1.6.3, but not
with CVS Automake (the upcoming Automake 1.7), so that's good news.
[...]
--
Alexandre Duret-Lutz
I wrote a top-level configure.ac that only
> specified the following outputs:
>
> AC_CONFIG_FILE(a/Makefile)
> AC_CONFIG_FILE(b/Makefile)
> AC_OUTPUT
>
> and when I ran automake on this I never got either of those Makefile.in's
> generated.
s/AC_CONFIG_FILE/AC_CONFIG_FILES/
--
Alexandre Duret-Lutz
>>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
> On Fri, Aug 02, 2002 at 07:55:43PM -0400, Harlan Stenn wrote:
> > I tried to write a test case for automake (debugging the AM_CONDITIONAL
> > slowdown problem I'm seeing) and I wrote a top-level configure.ac that
> > only specified
On Tue, Aug 13, 2002 at 02:29:47PM +0100, Patrick Welche wrote:
> On NetBSD, I get a failure for vtexi.test. The odd thing is that the test
> mentions:
>
> # Test for bug reported by Jim Meyering:
> # When I ran automake-0.29 on textutils,
> # I noticed that doc/Makefile.in had
> # textutils.inf
y time a user unpack your tarball and run make, src/example
is built. So src/example is new, and the above rule will
_always_ be triggered. So help2man'd better exist...
You get this distcheck failure because you are rebuilding a
distributed file.
[...]
--
Alexandre Duret-Lutz
#x27; form. So that means you don't
want to distribute example.8.
--
Alexandre Duret-Lutz
e, not make.
One way to achieve the same effect is to use AC_CONFIG_LINKS in
configure.ac. To preserve the abstraction of foo you could list
the AC_CONFIG_LINKS commands in foo/links.m4 and have
m4_include([foo/links.m4]) at the appropriate place in
configure.ac.
Or call a setup script with AC_CONFIG_COMMANDS.
--
Alexandre Duret-Lutz
ib'
Harlan> twice.
Could you fill a PR for this?
Harlan> So how do I get automake to shut up?
I guess a ugly workaround is to define COND3 as "COND1 or COND2"
and use that...
--
Alexandre Duret-Lutz
>>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
[...]
Harlan> Suggestions on how I can remedy this problem?
Yep. http://sources.redhat.com/ml/automake/2002-06/msg00199.html
--
Alexandre Duret-Lutz
_DIST variable
Bruce> when it is not in the SUBDIRS variable.
I'm not sure I understant what you want to do, but this last
statement sounds very odd. Why don't you simply use DIST_SUBDIRS?
[...]
--
Alexandre Duret-Lutz
nal) copy.
I aggree, but that's a secondary issue. You face this problem
(and others) because you have the same directory listed in both
SUBDIRS and EXTRA_DIST.
--
Alexandre Duret-Lutz
ood idea. Really. It means
you'll have a schizophrenic package that does not distributes
the same files in all configurations (e.g. the .deps you
mentioned).
Getting the right value in DIST_SUBDIRS (either automatically or
explicitely) is the way to go.
Bruce> [...] intended as an extended example [...]
A good reason not to use EXTRA_DIST.
[...]
--
Alexandre Duret-Lutz
y. You don't need to EXTRA_DIST it.
All you need is, in some place read by Autoconf (your macro?):
AM_CONDITIONAL([BAR], ...)
AC_CONFIG_FILES([bar/Makefile])
In the top-level Makefile.am
if BAR
MAYBE_BAR = bar
fi
SUBDIRS = foo $(MAYBE_BAR)
No evil EXTRA_DIST, no redefinition of DIST_SUBDIRS (since
Automake gets it right in this case), no related AC_SUBST.
--
Alexandre Duret-Lutz
read
if NEED_LIBOPTS
LIBOPTS_DIR= libopts-0.0.0
endif
^
[...]
Bruce> AC_SUBST(LIBOPTS_DIR)
You don't need this anymore, do you?
--
Alexandre Duret-Lutz
to recurse in all directories, even those which have been
conditionally left out of the build.
Precisely, `DIST_SUBDIRS' is used by `make dist', `make distclean',
and `make maintainer-clean'. All other recursive targets use `SUBDIRS'.
Automake will define `DIST_SUBDIRS' automatically from the possibles
values of `SUBDIRS' in all conditions.
If `SUBDIRS' contains `AC_SUBST' variables, `DIST_SUBDIRS' will not
be defined correctly because Automake doesn't know the possible values
of these variables. In this case `DIST_SUBDIRS' needs to be defined
manually.
-- Footnotes --
(1) Don't try seeking a solution where `opt/Makefile' is created
conditionally, this is a lot trickier than the solutions presented here.
--
Alexandre Duret-Lutz
"for/do/done" rule?
set fnord $$MAKEFLAGS; amf=$$2; \
case "$$amf" in *=*) set -e ;; *k*) ;; *) set -e ;; esac; \
The idea is to force `set -e' unless `make -k' is used.
This would free us from all these `|| exit 1'.
--
Alexandre Duret-Lutz
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
[...]
adl> What about adding something like the following on top of each
adl> "for/do/done" rule?
adl> set fnord $$MAKEFLAGS; amf=$$2; \
adl> case "$$amf" in *=*) set
al/.
See also `aclocal --print-ac-dir`.
Artur> Will these macros be used by automake 1.6 or they will
Artur> be ignored because they are not in automake-1.6?
They will be used. $(datadir)/aclocal-1.6/ is a private directory,
don't put anything in it.
In short: don't change the place exising packages install their macros.
--
Alexandre Duret-Lutz
`aclocal', and better diagnosed by
Automake 1.6.3 (may I suggest upgrading?).
[...]
David> So, you can see that what I'm trying to do is use $host_os to set
David> PDL_*. Then I use this information to later set various compile
David> options (LDFLAGS, etc.).
IMHO these flags would be better set from configure, but that's
another story.
[...]
--
Alexandre Duret-Lutz
gt; + return;
assar> +}
[...]
assar> --- /dev/null 1 Jan 1970 00:00:00 -
assar> +++ tests/libobj12.test 24 Aug 2002 03:34:58 -
assar> @@ -0,0 +1,30 @@
assar> +#! /bin/sh
assar> +
assar> +# $Id$
Ouch, please no! RCS-keywords are more anoying than useful.
[...]
--
Alexandre Duret-Lutz
still requires a convention for naming files (so the
installation routine can strip `.fr' without damage).
--
Alexandre Duret-Lutz
ts to read
`foo.texi'. However `foo.texi' might not exist yet at the time
Automake is run.
Sorry, I'm afraid this all isn't very helpful.
--
Alexandre Duret-Lutz
nguage, so they eventually get installed
in the right place.
Suggestions so far are to put this information in the source
filename. For instance teaching Automake to install
`pt_BR-foo.1' or `foo.1.pt_BR' as `pt_BR/man1/foo.1',
with the rewriting issues Josef pointed out.
--
Alexandre Duret-Lutz
ll your Makefiles use both
INSTALL_SNPRINTFV and pkgincludedir, so it shouldn't be that
hard to locate.
[...]
--
Alexandre Duret-Lutz
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
[...]
adl> However, I presume not all your Makefiles use both
adl> INSTALL_SNPRINTFV and pkgincludedir, so it shouldn't be that
adl> hard to locate.
You can also try `automake --verbose'
s application"
It's ok to list files from subdirectories in a _SOURCE variable.
bin_PROGRAMS = prog
prog_SOURCES = \
prog.c \
x/x1.c \
x/x2.c \
x/x2.c \
y/y1.c \
y/y2.c \
y/y2.c \
...
AUTOMAKE_OPTIONS = subdir-objects # If you want.
--
Alexandre Duret-Lutz
t; && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base installcheck \
Roger> && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base uninstall \
Unfortunately `make installcheck' isn't expected to run in a
DESTDIR installation as it might run programs which read files
using the real $prefix.
[...]
--
Alexandre Duret-Lutz
I tell automake?
Using _MANS you can't. Try using _DATA.
This was discussed a few weeks ago on this list.
[...]
--
Alexandre Duret-Lutz
Here is a snapshot of the current development version of Automake.
This should become Automake 1.7 *soon*. How soon will depends on
the feedback we get on this beta.
Please get it, install it, test it, torture it.
Please report any issue by mail to <[EMAIL PROTECTED]>,
or (preferred) using the
>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
[...]
Pavel> Well, my package doesn't. Here's the test (full test
Pavel> with copyright is attached):
Thanks a lot! I'm installing the following fix.
2002-09-19 Alexandre Duret-Lu
about non-POSIX `%'-style
pattern rules. This looks like duplicate rules for target
`${ARCH}/%.$(OBJEXT)' if you ignore what `%' means.
2002-09-19 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* automake.in (rule_d
>>> "Schleicher" == Schleicher Ralph (LLI) <[EMAIL PROTECTED]> writes:
[...]
Schleicher> I think there is an inconsistency between the
Schleicher> Automake documentation and actual program behavior.
Thanks a lot! I'm checking this in.
2002-09-19 Ale
mail/libtool/2002-August/006640.html
--
Alexandre Duret-Lutz
nce this script works for everyone who uses Automake
Pavel> CVS, aclocal.m4 and Makefile.in can be removed from CVS.
Pavel> But this step is optional.
I'd prefer not. I've found diffs on Automake-generated files a
valuable to check the effect of changes we do on Automake itself.
[...]
--
Alexandre Duret-Lutz
follow the CVS instructions shown here
http://sources.redhat.com/automake/
HEAD is what will become the upcoming 1.7.
branch-1-6 contains the 1.6.x versions, but it's dead now.
--
Alexandre Duret-Lutz
lways distributed.
* Use Autoconf's --trace interface to inspect configure.ac and get
a more accurate view of it.
* Add support for extending aclocal's default macro search path
using a `dirlist' file within the aclocal directory.
* automake --output-dir is deprecated.
* Many bug fixes.
- Akim, Alexandre, and Tom
--
Alexandre Duret-Lutz
E=x TESTS='cond5.test gettext.test gettext2.test subdircond.test' \
make -e check
Art> There is also a problem with building from CVS now that
Art> aclocal and automake aren't generated in the AC_CONFIG_FILES
Art> section.
Pavel recently committed a `bootstrap' script for this.
[...]
--
Alexandre Duret-Lutz
cept of "warning" is new in Automake 1.7.
Previous versions produced only errors, and it's likely there
are still many error messages we ought to change into warnings.
2002-09-22 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* automake.in (macro_define): Update a variabl
one as PR automake/350.
Harlan> Is there a workaround/bugfix?
Here is a workaround. Define FOO_AB as "FOO_A or FOO_B"":
AM_CONDITIONAL(FOO_AB, test x"$FOO" = xa || test x"$FOO" = xb)
then use FOO_AB to define lib_LTLIBRARIES in a single place.
--
Alexandre Duret-Lutz
u should run autoupdate.
Harlan> Line 64 is AM_PROG_LIBTOOL.
Harlan> Or am I missing something?
It's unrelated to Automake. `autoconf -Wobsolete' is speaking here.
--
Alexandre Duret-Lutz
onf
Harlan> --install".
ylwrap is needed only if you have more than one yacc/lex file in
a directory.
I'm installing the following patch.
2002-09-22 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* automake.texi (Yacc and Lex): ylwrap is used only when there is
mo
rstanding something?
You have to ask Automake for the other behavior. See the
description of the `subdir-objects' option in the manual.
--
Alexandre Duret-Lutz
801 - 900 of 920 matches
Mail list logo
