e AM_CFLAGS a global default value, and override this
definition locally in a Makefile.am if needed.
--
Alexandre Duret-Lutz
>>> "David" == David T Farning <[EMAIL PROTECTED]> writes:
David> 5. these header will be installed in prefix/includes via
David> _include_DATA =
include_HEADERS = ...
http://sources.redhat.com/automake/automake.html#Headers
--
Alexandre Duret-Lutz
>>> "Oliver" == Oliver B Fischer <[EMAIL PROTECTED]> writes:
Oliver> Alexandre Duret-Lutz wrote:
>> Either you haven't installed libtool, or you forgot to run aclocal
>> prior to autoconf and automake.
Oliver> Neither nor. Might it be
efine
DIST_SUBDIRS correctly itself. (Correctly means DIST_SUBDIRS
will include all directories that can possibly appear in
SUBDIRS.) See node `Top level' in the manual for a discussion
about conditional subdirectories.
--
Alexandre Duret-Lutz
On Fri, Jul 02, 2004 at 04:32:28PM -0700, Kevin Nowaczyk wrote:
> When the admin types `make install` I would like a
> file "project/doc/foo.conf" to be placed in
> "/etc/foo.conf".
>
> The configure script generated by autogen.sh contains
> the line:
> sysconfdir='${prefix}/etc'
>
> My question is
nd let automake do its job: the two files it lists are files
that automake would automatically distribute anyway.
* To distribute extra files, do use the documented variable
EXTRA_DIST.
* Running `automake -Wall' will warn you about user definitition
that overwrite automake variable (among other things).
[...]
--
Alexandre Duret-Lutz
libraries. Libtool might be able to produce DLLs under
MinGW, I don't know. So If there is a way, it will be using
_LTLIBRARIES and libtool.
--
Alexandre Duret-Lutz
>>> "Kevin" == Kevin Nowaczyk <[EMAIL PROTECTED]> writes:
Kevin> For some reason that doesn't work.
[...]
Kevin> I'm using automake version 1.4-p4
Why do you keep using this 3-year-old junk? Come on and
exchange your old bugs for fresh ones!
--
Alexandre Duret-Lutz
ets
Dale> overwritten.
autoheader creates the .in only for the first AC_CONFIG_HEADERS argument.
If you don't want your handcrafted template to be overwritten by
autoheader, register a dummy header first using
AC_CONFIG_HEADERS([config.h src/warped/WarpedConfig.h])
or
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_HEADERS([src/warped/WarpedConfig.h])
--
Alexandre Duret-Lutz
>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> There is an Automake bug in 'make distcheck' which is causing me
Bob> considerable pain.
See DISTCHECK_CONFIGURE_FLAGS is the manual.
--
Alexandre Duret-Lutz
Hi people,
This is a release candidate for Automake 1.9.
If you have some time, please help us tracking down bugs by trying
this beta with your packages and reporting any issue you encounter.
Especially, please shout loud if your package works with 1.8.5 but
does not with 1.8d.
I plan to release
27;^ *([^ \t=:+]*)\s*([:+]?)=\s*(.*)' . "\$";
[...]
> Would it be possible to add a warning to automake about such [1]
> tabs-vs-spaces oddities?
With the current sniffer, this sounds hard. But feel free to
give it a try...
--
Alexandre Duret-Lutz
We're pleased to announce the release of Automake 1.9.
This release contains many bug fixes and improvements, but not as much
as in previous major releases. The NEWS entry is appended. Thanks to
all people who have been testing pre-release, reporting bugs,
contributing code, suggesting enhanceme
with no avail.
Its `set env(LC_ALL) C'.
Check projects that do it for inspiration.
http://sources.redhat.com/ml/binutils/2002-07/msg00031.html
[...]
--
Alexandre Duret-Lutz
inutes on my high end Mac, and up
Gary> to an hour for some of our other developers :-(
Does it? Running ./bootstrap takes 8 minutes on my poor PC.
--
Alexandre Duret-Lutz
from...
Sam> configure.ac:322: the top level
Sam> configure.ac:322: warning: AC_RUN_IFELSE was called before AC_AIX
Sam> configure.ac:344: warning: AC_COMPILE_IFELSE was called before AC_AIX
Sam> configure.ac:344: the top level
Sam> configure.ac:344: warning: AC_RUN_IFELSE was called before AC_AIX
Sam> ...
Look easy to fix in your configure.ac.
--
Alexandre Duret-Lutz
7;t think so, but that would be welcome...
http://sources.redhat.com/automake/contribute.html
--
Alexandre Duret-Lutz
automake release. We are using
William> automake but not libtool so can't use libtoolize which is able to
William> install them. Also
William> automake --add-missing --copy --force-missing
There is a fix for this bug in CVS. Automake 1.9.1 will update
these files on such incantation.
--
Alexandre Duret-Lutz
>>> "William" == William S Fulton <[EMAIL PROTECTED]> writes:
William> Alexandre Duret-Lutz wrote:
>>>>> "William" == William S Fulton <[EMAIL PROTECTED]> writes:
William> We are using AC_CANONICAL_HOST which requires config.sub
&
.
Existing file are only overwritten when you supply `--force-missing'.
--
Alexandre Duret-Lutz
uess
William> installed?
Automake only reads *.am files. Either you should use a
top-level Makefile.am, or you should update these files yourself
(it's not unusual to wget them from their CVS repository before
release -- see Automake if you need an example).
--
Alexandre Duret-Lutz
ns. E.g., does `info'
supports several translated versions of a manual? If yes, where
should they be installed and how should they be named? (I see
nothing about this in the Texinfo manual, but maybe there are
plans for this.)
--
Alexandre Duret-Lutz
l, compile, etc... but make distcheck complains that
Xavier> it cannot find foo.i!! But it *is* in the tarball?!? I don't get at
Xavier> all what's happening here.
It cannot find foo.i in the build directory because it is in the
source directory.
--
Alexandre Duret-Lutz
nd that a file
is to be distributed, and remove it in its back), especially when you
have ways to express the truth (using dist_/nodist_).
--
Alexandre Duret-Lutz
We're pleased to announce the release of Automake 1.9.1.
This is a tiny bug-fix release motivated by (1) the Debian GNU/Linux
freeze, and (2) a three-week vacation starting in a couple of days :)
The list of bug fixes is appended; we have not yet heard about
regressions introduced by 1.9.
You can
actice for this?
foodir = $(includedir)/foo
foo_HEADERS = mumble.h
--
Alexandre Duret-Lutz
>>> "Xavier" == Xavier Décoret <[EMAIL PROTECTED]> writes:
[...]
Xavier> What is the correct variable to ask for removal of a file. Is this
Xavier> $(rm) or something like this?
rm is a constant.
--
Alexandre Duret-Lutz
On Tue, Sep 07, 2004 at 10:18:32AM +0200, Thomas Degris wrote:
> Hello,
>
> I would like to know how do I install (by default) all the libraries in
> $prefix/lib/my_package instead of $prefix/lib.
Use pkglib_LIBRARIES or pkglib_LTLIBRARIES in your Makefile.am.
>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
[...]
Andreas> 2004-08-30 Andreas Schwab <[EMAIL PROTECTED]>
Andreas> * automake.in ($PATH_PATTERN): Add `+'.
Committed. Thanks.
--
Alexandre Duret-Lutz
lding
client xxx, the client will be relinked whenever libwhatever.a
has changed.
--
Alexandre Duret-Lutz
.13. If
you are running the above example and the failing configure from
the very same shell session, it might be caused by a shell
configuration that mistakenly reset PATH for non-login shells.
--
Alexandre Duret-Lutz
>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
[...]
Bob> Apparently when automake is executed to generate Makefile.in, some
Bob> saved information is OS-dependent. That is bad.
I'd love a diff between those two different Makefile.in, then.
[...]
--
Alexandre Duret-Lutz
ONAL to
enable/disable these rules. That sounds cleaner than any hook
hackery.
--
Alexandre Duret-Lutz
on, Inc.
+# Copyright (C) 2003, 2004 Free Software Foundation, Inc.
#
# This file is part of GNU Automake.
#
@@ -33,8 +33,9 @@
END
cat > Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
lib_LTLIBRARIES = libmod1.la mod2.la
-libmod1_la_SOURCES = mod1.c
+libmod1_la_SOURCES = sub/mod1.c
libmod1_la_LDFLAGS = -module
libmod1_la_LIBADD = -dlopen mod2.la
mod2_la_SOURCES = mod2.c
@@ -50,9 +51,9 @@
END
-mkdir liba
+mkdir sub liba
-cat > mod1.c << 'END'
+cat > sub/mod1.c << 'END'
int
mod1 ()
{
--
Alexandre Duret-Lutz
>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
[...]
Bob> there is still a difference in the generated Makefile.in
Bob> files.
Good catch, thanks! I'm installing the following on HEAD and branch-1-9.
2004-09-07 Alexandre Duret-Lutz <[E
make distcheck', make distcheck fails due to
Bob> the distribution files being left behind in the test directory.
That does not ring a bell. Could you provide instructions to reproduce
this on an existing package or on a test case?
--
Alexandre Duret-Lutz
ght consider using James
Henstridge's ltihooks.py to import libtool libraries directly
from Python. You can find ltihooks.py in pygtk. I'm using it
in Spot (spot.lip6.fr) to load Swig generated libtool modules.
--
Alexandre Duret-Lutz
o files.
[...]
Gary> Meant to ask, why doesn't AM_INIT_AUTOMAKE (conditionally if
Gary> necessary) simply invoke AM_PROG_CC_C_O?
We know it's needed only after processing the Makefile.am files.
--
Alexandre Duret-Lutz
e the line continuation
| request.
This happens in *some* Make implementations. However this is
contrary to POSIX. See `Escaped newline in comments' paragraph
in the `Limitations of Make' section of the Autoconf manual.
--
Alexandre Duret-Lutz
On Fri, Sep 10, 2004 at 09:33:30AM -0500, Bob Friesenhahn wrote:
> My non-recursive Automake project (based on latest Automake CVS)
> places objects in subdirectories. The project uses libtool to build
> all objects. However, Automake complains:
>
> % automake
> Makefile.am: C objects in subdir b
name of one file that is built with -c -o without libtool.
--
Alexandre Duret-Lutz
achieved by custom rules, of
course; but (1) that can constitute a good source of inspiration
and (2) converting AdaSockets to whatever way it chosen to
support Ada in Automake would be a good test.
--
Alexandre Duret-Lutz
? autom4te.cache
? buffer-warnings.patch
? exeext.patch
? x
? m4/ada.m4
? tes
We're pleased to announce the release of Automake 1.9.2.
This is a small bug-fix release (the list of bugs fixed is
appended), and this is also an anniversary release.
Automake was started on 1994-09-19 so it has 10 years today.
To celebrate this the manual has been augmented with a
"History"
but I haven't flushed all my mails yet.
I agree it would be better to set down a common lock scheme,
although that really should not hold any release.
--
Alexandre Duret-Lutz
AC_PROG_RANLIB, etc.
I once thought that since Automake knew what extra macros where
required, it could generate a configure.ac fragment with these.
But that sounds too fragile and tricky.
--
Alexandre Duret-Lutz
nk holding this patch is that it adds a new language
without documenting it.
--
Alexandre Duret-Lutz
me? In other words, the `compile' script needed for
C compilers, and since we use C compilers to compiler asm, do
we need the `compile' script too?
--
Alexandre Duret-Lutz
Hi,
On Mon, Oct 11, 2004 at 02:20:30PM +0100, Milan Tichy wrote:
>
> I used both AC_PROG_CC_C_O and AM_PROG_CC_C_O but it didn't help.
Could you state your Automake version and post a copy of your configure.ac?
e}bj"; then
+ mv "${cofile}bj" "$ofile"
fi
rmdir "$lockdir"
--
Alexandre Duret-Lutz
are not programs. If that used to work in 1.8 it was a bug.
--
Alexandre Duret-Lutz
' section of the manuals.)
--
Alexandre Duret-Lutz
their full
output.
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
--
Alexandre Duret-Lutz
e manual, the section `Building a Shared
Library' was revamped last year.
--
Alexandre Duret-Lutz
, and I recommend against it. A distributed
file should never depend upon a non-distributed built file (see
also node distcleancheck in the FAQ).
--
Alexandre Duret-Lutz
but this is just not supported
presently. (Unless you overwrite a significant portion of the
variables and rules generated by Automake, or arrange to rename
these files before distribution.)
--
Alexandre Duret-Lutz
invalid variable `dist_bin_SCRIPTS'
saiph> Makefile.am:1: invalid variable `dist_bin_SCRIPTS'
saiph> make: *** [Makefile.in] Error 1
saiph> after i have googling for it i found it was a fixed old bug..
Indeed it is: this is Automake 1.4 speaking. In other words you
are not running the version you think you are.
--
Alexandre Duret-Lutz
dummy.f
so that the file does not have to exist. That's the way I do too.
--
Alexandre Duret-Lutz
>>> "Jens" == Jens Rehsack <[EMAIL PROTECTED]> writes:
[...]
Jens> Are there any tips how to write such Makefile.am's?
Consider using Libtool convenience libraries for your
subdirectories (there is a section about this in the Automake
manual).
--
Alexandre Duret-Lutz
you could modify it to show how to
reproduce your problem?
--
Alexandre Duret-Lutz
pt.o
Peter> ./getopt1.o
Peter> ..., not in the libgetopt directory. Thus, compilation fails
Peter> because the linker won't find the files.
Peter> Is there any simple way to fix this?
Sure:
AC_LIBOBJ([getopt])
AC_LIBOBJ([getopt1])
--
Alexandre Duret-Lutz
On Tue, Oct 26, 2004 at 02:01:18PM +0200, Peter Simons wrote:
> Alexandre Duret-Lutz writes:
>
> >> AC_LIBOBJ(libgetopt/getopt)
> >> AC_LIBOBJ(libgetopt/getopt1)
>
> > AC_LIBOBJ([getopt])
> > AC_LIBOBJ([getopt1])
>
> Then automake / autoconf
On Tue, Oct 26, 2004 at 02:43:26PM +0200, Alexandre Duret-Lutz wrote:
> On Tue, Oct 26, 2004 at 02:01:18PM +0200, Peter Simons wrote:
> > Alexandre Duret-Lutz writes:
> >
> > >> AC_LIBOBJ(libgetopt/getopt)
> > >> AC_LIBOBJ(libgetopt/getopt1)
> >
On Tue, Oct 26, 2004 at 04:35:26PM +0200, Peter Simons wrote:
> Alexandre Duret-Lutz writes:
>
> > It occured to me that maybe you were trying to use
> > $(LIBOBJS) outside of libgetopt/Makefile.am. Don't.
> > $(LIBOBJS) is expected to be used only in the director
We're pleased to announce the release of Automake 1.9.3.
This is a bug-fix release, the list of bugs fixed is appended.
You can find the new release here:
ftp://ftp.gnu.org/gnu/automake/automake-1.9.3.tar.gz
ftp://ftp.gnu.org/gnu/automake/automake-1.9.3.tar.gz.sig
ftp://ftp.gnu.org/g
n your Makefile.am.
Note that if your install-{exec,data}-local target creates a
directory and you care about the GNU Coding Standards, you
should also create this directory in installdirs-local.
--
Alexandre Duret-Lutz
ng) are intermixed into aclocal.m4.
(Seems another good reason to prefer setups with m4_include).
(*) Amusingly, Automake's own aclocal.m4 is probably the only
aclocal.m4 where there is no such confusion.
--
Alexandre Duret-Lutz
the file were m4_included (we don't do that for Automake
macros anyway, but is that a reason to disallow it?)
--
Alexandre Duret-Lutz
erms that
you use for the rest of the package.
"configuration script generated by Autoconf" is what the aux
scripts already use.
"or any derived output" is a lame attempt to allow tools such as
aclocal (without singling out aclocal) to preprocess the file,
as long as the intent is to build a configure script.
--
Alexandre Duret-Lutz
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Alexandre Duret-Lutz wrote:
[...]
>> I don't understand the intent of "as input to GNU Autoconf, GNU
>> Automake, or GNU Libtool". AFAICT Libtool does not input m4
>>
; script (and perhaps some associated intermediate files),
Paul> then you may distribute this file and the derived files
Paul> for that purpose, under the same terms that you use for
Paul> the rest of the package.
[...]
President Eggert, you have my vote!
--
Alexandre Duret-Lutz
on't know: the test suite displays $PATH right before the start
of your quote. It should use
/usr/src/local/automake/tests/aclocal-1.9a, which itself
redirects to /usr/src/local/automake/aclocal.
Please do direct bug reports to [EMAIL PROTECTED], a spurious
failure of CVS Automake is noise fo
create one?
No. Simply append regex.m4 to your package's aclocal.m4.
--
Alexandre Duret-Lutz
orth fixing
Peter> and c) there is probably a "better way".
[...]
d) the patch is more than 15 lines and you haven't signed
copyright papers for Automake. Would you do that?
--
Alexandre Duret-Lutz
Please email the following information to [EMAIL PROTECTED], and we
will send you t
>>> "Bob" == Bob Proulx <[EMAIL PROTECTED]> writes:
Bob> There is no mention of bug-automake on the web page.
Bob> http://www.gnu.org/software/automake/
Thanks. I added a link to the Automake home page, which has
up-to-date info in this regard.
--
Alexandre Duret-Lutz
>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes:
[...]
>> gmake[5]: Warning: File `autogen' has modification time 1.8 s in the future
[...]
I suggest you complain to your system administrator.
--
Alexandre Duret-Lutz
IG_MACRO_DIR to way you thought. It certainly isn't the
Automake manual.
See also
http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00097.html
--
Alexandre Duret-Lutz
libdi.a
instead shouldn't be a big deal.
noinst_LIBRARIES = libdi.a
libdi_a_SOURCES = di_dudata.c di_di.c di_dumd.c ...
[...]
Roesner> I have not found any hint in the web,
`info automake' is your friend.
--
Alexandre Duret-Lutz
R, `aux_config'.
J> Makefile.am:34: required directory ./TAO does not exist
J> autoreconf: failed to run automake: No such file or directory
J> Any suggestions?
I'm augmenting the aforementioned section with the following bits.
2004-11-24 Alexandre Duret-Lutz <[EMAIL PROTECTE
he manual
is not recreated (which is undoubtedly what you want, otherwise
you wouldn't distribute it).
Hence either the install rule is wrong in assuming that the manual is
always in the build directory, or the build rule is wrong in building
the manual in the build directory.
I suggest you always build distributed files in the source
directory. (BTW this is mandatory if you want to support VPATH
builds with some non-GNU implementation of make.)
--
Alexandre Duret-Lutz
clude_HEADERS into two variables or
more, so that two install rules get generated.
pkginclude1dir = $(pkgincludedir)
pkginclude2dir = $(pkgincludedir)
nobase_pkginclude1_HEADERS = ...
nobase_pkginclude2_HEADERS = ...
Maybe there is a better way?
--
Alexandre Duret-Lutz
en a user
attempt a VPATH build. There is no point in distributing
the doc if users have to rebuild it anyway.)
--
Alexandre Duret-Lutz
27;.
Using variables like this gives you full control on the ordering of
the flags. For instance if there is a flag in $(WARNINGCFLAGS) that
you want to negate for a particular target, you can use something like
`prog1_CFLAGS = $(AM_CFLAGS) -no-flag'. If all these flags had been
forcefully appended to `CFLAGS' there would be no way to disable one
flag. Yet another reason to leave user variables to users.
Finally, we have avoided calling the variable `LIBFOO_LDFLAGS' (with
an underscore), because that would cause Automake thinking that this is
actually a per-target variable (like `mumble_LDFLAGS') for some
non-declared `LIBFOO' target.
--
Alexandre Duret-Lutz
onardo> *FLAGS variables. Is that correct?
Yes. Oh well, almost. You cannot really lump LDADD and LIBADD
together: there is no LIBADD variable, only per-target _LIBADD
variables. To some extent, LIBADD is less confusing than LDADD.
Leonardo> It may sound obvious, but I find it confusing =)
I confess I once wrote AM_LDADD in a Makefile.am. (To make
matters worse, that was while teaching someone else how to write
a Makefile.am for his package!)
--
Alexandre Duret-Lutz
Files under CVS'' in
Stepan> the gettext manual.
Speaking of manuals, the FAQ section of the Automake manual also
have a node called "CVS" and listing pros, cons, and workarounds.
--
Alexandre Duret-Lutz
Unlikely: Automake 1.8 requires Autoconf 2.58 or greater.
--
Alexandre Duret-Lutz
er than explicitly listing this
Robert> subdirectory, adding a Makefile.am there, ... since there's
Robert> nothing to build there?
Yes. However you'd better use noinst_HEADERS instead of
EXTRA_DIST so that `make tags' and friends process the headers.
--
Alexandre Duret-Lutz
ts of an automake-generated Makefile.in.) I believe the simplest
solution is to call libtool as you always did, and simply add the
missing --tag=CXX option.
[...]
--
Alexandre Duret-Lutz
n't intend to accept a patch for
Guillaume> every minor research language in the world.
Indeed.
--
Alexandre Duret-Lutz
On Sun, Dec 05, 2004 at 03:26:30PM -0600, Robert Lowe wrote:
> A make distcheck with this example fails
How?
/`.obj' extensions,
and all the other flags variables involved in a compilation, you will
end up modifying a copy of the rule previously output by `automake' for
this file. If a new release of Automake generates a different rule,
your copy will need to be updated by hand.
--
Alexandre Duret-Lutz
AULTFLAGS) $(O3)
as appropriate.
($(O3) being the Makefile variable that contains -O3 if the compiler
support it).
Does that sound sensible?
--
Alexandre Duret-Lutz
n was delivered to your mailbox 10 days ago.
It will be in 1.9.4.
From: Alexandre Duret-Lutz <[EMAIL PROTECTED]>
Subject: RFC for new FAQ entry: Flag Variables Ordering
To: [EMAIL PROTECTED]
Date: Tue, 30 Nov 2004 01:49:07 +0100
--
Alexandre Duret-Lutz
We're pleased to announce the release of Automake 1.9.4.
This is a bug-fix release, the list of bugs fixed is appended.
You can find the new release here:
ftp://ftp.gnu.org/gnu/automake/automake-1.9.4.tar.gz
ftp://ftp.gnu.org/gnu/automake/automake-1.9.4.tar.gz.sig
ftp://ftp.gnu.org/g
pe> hello_cc_SOURCE = hello_cc.cc
Philippe> endif
s/_SOURCE/_SOURCES/
If no `target_SOURCES' variable is specified it defaults to `target.c'.
--
Alexandre Duret-Lutz
upposed to work without the need
JRBCAST> of autotools presence?.
Yes it is, as long as the timestamps are preserved.
--
Alexandre Duret-Lutz
nd shouldn't the LDFLAGS be last? It is in CXXLINKS, but in the
Akim> command line.
Fixed in the patch below as a side-effect of using maude_LDFLAGS
instead of AM_LDFLAGS.
2004-12-26 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
Fix handling of per-target flags in link rul
Thank for the suggestion. This is similar to PR/383 so I've
added your email to the Cc: list for this PR.
--
Alexandre Duret-Lutz
ng filenames even before
the tar-* option were introduced. Hence filename-length-max=99
was suggested as an option only for those who care.
--
Alexandre Duret-Lutz
>>> "J" == J T Conklin <[EMAIL PROTECTED]> writes:
J> I've since learned that the problem isn't in autoconf, but in
J> automake.
It was. More than one year ago.
--
Alexandre Duret-Lutz
t; long been fixed.
My bad. I though you were talking about an AC_CONFIG_FILE input that
is the output of an earlier AC_CONFIG_FILE.
--
Alexandre Duret-Lutz
401 - 500 of 920 matches
Mail list logo