I'm generating a site-local file during configure that I use in
AC_CONFIG_FILES.
The filename is in the $GUTS variable, and I create the target via:
GUTS=$build_cpu-localname
echo stuff $GUTS
AC_CONFIG_FILES([foo:foo-top.in:$GUTS:foo-bot.in])
The problem is the generated Makefile.in has
Not sure if this is an automake or an autoconf problem, and I['m putting out
too many fires tonight.
For a Long Time I've noticed the following output at the beginning of each
"configure" run under Ultrix:
configure: loading cache /dev/null
checking build system type... mips-dec-ultrix4.4
+ eval ${SHELL} /pogo/users/stenn/src/ntp.001227/missing --run :
I believe this can't be a problem in autoconf, since the `missing'
script is maintained as part of automake and, indeed, the test to
check whether it supports the `--run' switch relies upon `:'.
Does missing work if,
I think "layers" of config.site would be useful for parts of autopackage.
There are other a number of packages out there that attempt to solve this
problem in different ways, with varying degrees of success.
One set of extremes is the GNU stow project v. the Modules project.
Lately I'm playing
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 .
We're using different language. For example,
I did a cvs update of the latest automake and autoconf tonight.
I have one generated Makefile that now contains several lines of the form:
@_am_include@ $(DEPDIR)/foo.Po
I'm pretty sure I did a clean build/install of these versions of automake
and autoconf.
I did an "autoreconf -f" in the
I thought we fixed this (twice), but I'm still seeing it:
configure: loading cache /dev/null
checking build system type... mips-dec-ultrix4.4
checking host system type... mips-dec-ultrix4.4
checking target system type... mips-dec-ultrix4.4
checking for a BSD compatible install...
Ah! My configure still has:
if eval $MISSING --run :; then
I'll update automake again. Strange - I've tried to keep automake
reasonably up-to-date.
Would you prefer I used the wrapped tarball or the CVS version?
Harlan
--
Harlan == Harlan Stenn [EMAIL PROTECTED] writes:
Harlan I
And is another problem that the rules that handle ansi2knr conversion
create an empty foo_.c file if ansi2knr doesn't exist?
Harlan
I'll infer my previous response was correct:
...
cc -E -DHAVE_CONFIG_H -I. -I../../libntp -I.. -I../../include -I../../librsaref `if
test -f ../../libntp/adjtime.c; then echo ../../libntp/adjtime.c; else echo adjtime.c;
fi` | sed 's/^# \([0-9]\)/#line \1/' | ../util/ansi2knr adjtime_.c
Sure, how can I help?
I bet the first thing is to get CVS automake on that box...
Harlan
The failure is happening on a SunOS 4.1.3 box with cc and GNU make
(3.76.1). The build is being done outside of the source tree:
% mkdir A.`config.guess`
% cd !$
% ../configure
% make
As I recall, the problem did not happen on a 4.1.3 box with gcc and GNU
make 3.74 .
I'm trying to install
Evil.
Neither GNU make nor /bin/make catch the $(ANSI2KNR) dependency.
However, if I move the lines:
ANSI2KNR = ../util/ansi2knr
../util/ansi2knr:
cd ../util $(MAKE) $(AM_MAKEFLAGS) ansi2knr
from their current position in the Makefile (late, after the targets
that refer to them) to
That patch works for me.
Harlan
A tarball generated by make dist using the patch compiled just fine on
a bunch of machines.
I haven't tried a maintainer version yet on the same flock of
machines, but I'm pretty comfortable thinking we have this one licked.
I'll make a backup copy of a working automake and check out the latest
Akim Could the fact that we are using a macro for the dependency be
Akim responsible? Harlan, what happens if you replace the macro
Akim invocation with its value?
This has something to do with it.
With the late fragment:
...
a_md5encrypt_.c: a_md5encrypt.c $(ANSI2KNR)
@echo
This sounds familiar to me - I think I ran in to the same problem under
FreeBSD on a configure.in script that only wanted to find the X directories
(header and libs). I had to specify AC_PROG_CC to solve the problem.
H
I have an automake/autoconf application where the auto* generated stuff has
to co-exist with a different make application, and cannot use [Mm]akefile
for the names of the generated targets.
I have a solution for this for the flat case, but I now have to do a
SUBDIR case, too.
In the main
So I've done some digging into the *.Po problem I mentioned the other day.
I get the following warning message:
libntp/Makefile.am:18: required file `libntp/*.c' not found
and line 18 is:
libntp/Makefile.am:libntp_a_LIBADD = @LIBOBJS@
The only other place that LIBOBJS is mentioned is the
It looks like Something is creating a file called .deps/*.Po, and there are
apparently some native make implementations that Really Hate this.
I've noticed it for a While, and it's still happening with automake 1.5 .
Thoughts/suggestions?
H
Anybody have a framework for using automake (and perhaps autoconf) to
generate a Makefile.PL for a perl module?
I have a package that is already under auto* and somebody has a related perl
module; I was thinking it might be nice if make dist would handle creating
the pm's perl-mod-X.YY.tar.gz
I have a Makefile.am where I (think I) really want to override
RECURSIVE_TARGETS. This is because the SUBDIRS have Makefiles that are
generated from elsewhere and don't have all of the recursive targets (I
only need a few of them and it will be Difficult/politically incorrect to
add dummy
So I've been doing some digging and I don't see how to work around this
problem.
automake-1.5 will not let me override RECURSIVE-TARGETS.
I've added empty rulesets for:
dvi:
dvi-am:
dvi-recursive:
and distcheck is *still* trying to do a make dvi in the SUBDIR.
Ideas?
In the fragment
I'm noticing a problem with automake-1.5 and the transform rule.
Specifically, I'm working with CVS amanda-2 and the --with-suffix option
The Makefiles generated by automake-1.5 have a transform definition that
ends with a semicolon followed by a space, and the stock sed on FreeBSD-4
hates this
First, I think the ctags/etags example in the docs are wrong, at least
in the more complex example that describes de-ANSI-fication. In both
the examples the input should be coming from a ._c file and the
resulting file should be a ._o file. Perhaps better, a combined example
that uses $U? And
| autoconf handles AC_CONFIG_FILES($foo) properly.
But I should say it is not recommended! The documentation asks for
literals whenever it is possible.
Yes, and I agree with it in general.
| A plain invocation of automake rightly complains that it has no idea what
| it needs to look at,
First, I will say that I have been given a task and I don't fully understand
everything that is going on with it.
As I understand it, the project in question is an embedded application so
production installs must be stripped to conserve space.
The strip options for programs are too aggressive
install.am hardwires the INSTALL_STRIP_FLAG to -s.
I think this is a lose - there are cases (like installing kernel modules for
an embedded system) where one wants to do a stripped install but -s is too
much.
In the existing code there is apparently no way to override this.
What's a good
Would it be OK to say:
INSTALL_STRIP_FLAG=$${INSTALL_STRIP_FLAG:-s} \
in lib/am/install.am?
I'm not sure about 3 things:
- if I quoted that right
- if ${foo:-value} is sufficiently portable
- if it's Bad to leave INSTALL_STRIP_FLAGS set in general
In this last case, it might be a
Some of you might remember a message I posted here a while ago where I was
(implicitly) using LIBOBJS (or whatever, it was a side effect of
AC_REPLCE_FUNCS) and getting messages about *.c not being found.
I solved this last problem (with 1.5 and 2.53) by changing my
Makefile.am's to not use that
There's no point in listing the .xpm files in noinst_DATA if you're
going to list them in EXTRA_DIST. Why did you do this?
Probably because based on his original query I told him to put the .xpm file
in noinst_DATA and I did not mention EXTRA_DIST at all. At that time,
nobody had seen the
Harlan The strip options for programs are too aggressive for kernel
Harlan modules.
Harlan Some Makefile.am's will install both programs and kernel
Harlan modules.
Harlan What are the choices for altering the strip flags?
You have a few choices.
You could set the INSTALL* macros at
So what options exist for making a single top-level monolithic Makefile.am?
I can't imagine keeping this file up-to-date by hand, especially on a large
project where changes must be frequently made by multiple developers.
Ideas?
H
Does anybody have some examples of how this works?
And is it possible to go to any spot in the tree and have a make do a
monolithic (non-recursive make) build of the descendent hierarchy?
H
So I have two projects that exhibit the behavior where I have the auto*
tools installed and when I update, say, Makefile.am and re-run a make, I
get the WARNING: `automake' is missing on your system... message.
This is, of course, not true. automake is there, in the path.
Any ideas on what is
First, I'm not saying this is a good idea.
I'm working on a project where Somebody decided it would be a feature to
hack the automake templates to permit subdirs to be built in parallel.
They implemented an additional level of locking to prevent, for example, a
library that is needed by
Here's what I think is happening.
There's an application that uses libtool. All of the places where
somebody wants to use a library it is specified via $(libfoo_la_LIBDEP), and
we run a wrapper script before we run the first make that scans all of the
Makefiles and builds:
libfoo_la_LIBDEP =
the
subdir makefile fragments into one big happy
make; then no special locking is needed.
(A la recursive make considered harmful.)
Boy, that's a big change, though.
- Dan
-Original Message-
From: Harlan Stenn
To: [EMAIL PROTECTED]
Sent: 5/17/2002 5:41 PM
Subject: Parallel builds
The mpkg folks apply a patch to automake to allow it to support
ACLOCAL_PATH.
This is most useful for places that want to support multiple versions of
libtool and keep the libtool installation independent of any installed
versions of automake.
I don't have easy access to any of my CVS automake
An application I'm working with preprocesses the Makefile.am's to find the
ones that build libraries, and creates a file that contains the path to each
library:
libfoo_la_LIBDEP = /path/to/libfoo.la
libbar_la_LIBDEP = /path/to/libbar.la
...
ALL_LIBS = \
/path/to/libfoo.la \
And I also tried:
AC_CONFIG_FILES(Makefile:global-vars.mk:Makefile)
H
So scan_autoconf_config_files() says:
...
# Handle $local:$input syntax. Note that we ignore
# every input file past the first, though we keep
# those around for later.
my ($local, $input, rest) = split (/:/);
...
and then only checks the $input
I'd like to discuss this problem and possible solutions with anybody who
understands the guts of automake well enough to do so.
H
== Harlan Stenn [EMAIL PROTECTED] writes:
Harlan The mpkg folks apply a patch to automake to allow it to support
Harlan ACLOCAL_PATH.
Harlan This is most useful for places that want to support
Harlan multiple versions of libtool and keep the libtool
Harlan installation independent of any
I've been looking thru the docs and I I haven't found a way to do the
following.
I am using automake and autoconf.
I am assuming:
- build means the arch of the build machine
- host the arch of the place where built stuff gets run
autoconf detects build != host and sets up for a cross-compile.
I've coded but haven't tested the suggestion I got for a fix.
I'll be back at work in a week and a half (or so) and will try it then.
H
--
Harlan == Harlan Stenn [EMAIL PROTECTED] writes:
Harlan I'd like to discuss this problem and possible solutions with
Harlan anybody who understands
I have a report that indicates that as the number of AM_CONDITIONAL()s
increases, the time it takes to run automake increases Significantly.
This is with automake-1.5.
I'm about to dive in and look at what's going on to be sure, but just in
case, does anybody have any information on what might
THanks!
H
Here are the results of my testing:
someconditionals/:
automake-1.5:249.480u 2.660s 4:42.35 89.3% 0+0k 0+0io 341pf+0w
automake-1.6.3: 341.810u 2.840s 6:07.24 93.8% 0+0k 0+0io 356pf+0w
moreconditionals/:
automake-1.5: 1134.130u 6.730s 21:27.70 88.5% 0+0k 0+0io
I've done a bit more testing.
The slowdown happens if I only modify 1 Makefile.am, and it seems to be
related to using SUBDIRS inside an AM_CONDITIONAL.
If I change the Makefile.am to use a non-SUBDIRS variable inside the
conditional autmake zips right along.
In fact, if I specify an as-yet
Bug, I'd guess.
Why does automake/autoconf assume it is in charge of the directory
structure?
H
--
On Sat, 2002-08-03 at 09:55, Harlan Stenn wrote:
Is it a bug or a feature that when using automake+autoconf there Must be a
top-level Makefile?
I tried to write a test case for automake
:
Although the code{SUBDIRS} macro can contain configure substitutions
(e.g. samp{DIRS}); Automake itself does not actually examine the
contents of this variable.
H
--
On Sat, 2002-08-03 at 09:50, Harlan Stenn wrote:
I've done a bit more testing.
The slowdown happens if I only modify 1
do not use Automake
(such as code{gettext}).
so there is clearly an intention/awareness of wanting to play nice with
other software.
H
--
On Sat, 2002-08-03 at 10:02, Harlan Stenn wrote:
Bug, I'd guess.
Why does automake/autoconf assume it is in charge of the directory
structure?
I'll
I typed it correctly in configure.ac and incorrectly in my email.
H
--
On Fri, Aug 02, 2002 at 07:55:43PM -0400, Harlan Stenn wrote:
Is it a bug or a feature that when using automake+autoconf there Must be a
top-level Makefile?
I tried to write a test case for automake (debugging
Automake-1.6.3.
So I have a Makefile.am that build both PROGRAMS and LTLIBRARIES.
One of the .c modules is used by both a program and a library.
I get the warning:
automake: foo/Makefile:NN: object `foo.$(OBJEXT)' created both with libtool
and without
and I'm assuming it's because this
I hope I didn't ask about this one already.
I have a Makefile.am that uses conditionals:
foo/Makefile.am:
if COND1
libfoo = libfoo.la
endif
if COND2
libfoo = libfoo.la
endif
...
lib_LTLIBRARIES = $(libfoo)
and when I run automake-1.6.3 on it I get:
automake: foo/Makefile.am:
Is there anything in the CVS repo that will not be part of the next automake
release?
IE, what do I want to use if I want to get the release candidate?
H
I'm using autoconf-2.54 and CVS automake (current).
I'm getting a bunch of messages of the form:
configure.in:51: `CFLAGS' is a user variable, you should not override it;
configure.in:51: use `AM_CFLAGS' instead.
which is irritating but probably cool.
What is not cool is that line 51 of
This appears to be aproblem with libtool+automake; if I use a static library
(no libtool) I don't see this problem.
Is there a workaround/bugfix? This problem means that autoreconf bails with
an error...
(Yes, I've tried a couple of other choices, like using a variable in the
conditionals and
If I enable warnings with CVS automake and run autoreconf, AM_PROG_LIBTOOL
generates a warning:
configure.in:64: warning: The macro `AC_FD_CC' is obsolete.
You should run autoupdate.
Line 64 is AM_PROG_LIBTOOL.
Or am I missing something?
H
I'm not sure if this is a bug or a feature.
The documentation says:
The `ylwrap' program is distributed with Automake. It should appear in
the directory specified by `AC_CONFIG_AUX_DIR' (*note Finding
`configure' Input: (autoconf)Input.), or the current directory if that
macro is not used
Harlan I'm asking because we have discovered that (since
Harlan automake/1.5, at least) ylwrap is not being installed by
Harlan either automake --add-missing or autoreconf --install.
Does this still happen with 1.6 and the current 1.7 prerelease?
I remember some fixes in this area between
Sorry if this is lame, but it's been a Long Day and I'm wasted.
It looks like grub-0.92 has Difficulty with ac-2.54 and am-CVS.
The problem is that grub likes the old style of AS rules, and current
automake/autoconf Really Want grub to use AM_PROG_AS. Making this change
means asm.S no longer
I'm noticing a change from 1.5 to 1.7 regarding subdir-objects.
I had to upgrade the automake/autoconf usage of ucd-snmp. Not fun.
I had things working with am-1.5. I'm having dependency issues with
am-1.7.
In particular, agent/Makefile.am uses configure to build a list of files:
Harlan Just to ask, what is the problem if the same library is
Harlan installed in two different places?
Automake produces only one rule to link the library, and
therefore doesn't know how to set `-rpath' correctly. See
PR/285.
So what is the problem with:
if COND1
lib_LTLIBRARIES =
Re: glob v. list
Why not provide both mechanisms, and let people use what they want?
Personally, I've been bitten far more often with globs and would tend to
explicitly list files. But that's my policy decision and this is really a
mechanism question.
H
I find that automake-1.7* (at least) complains about lines like:
if COND_FOO
VPATH=$(srcdir):$(srcdir)/../foo
endif
in Makefile.am's (VPATH was already defined in condition TRUE, which implies
COND_FOO).
Bug or feature?
H
I submitted a patch to handle this a while ago. Don't know what happened to
it.
H
But if I echo either $top_srcdir or $top_builddir, in the file
tests/foo.test, they are both null, so I can't seem to find a way of
referring to any files.
AC_OUTPUT your test scripts using foo.in - foo rules, and include lines
like:
[EMAIL PROTECTED]@
in them.
Either that, or AC_OUTPUT a
I'm trying to find a way to have automake generate Makefiles that will
automatically generate digital signatures for distributions, and trying to
figure out a good way to handle it.
I think the easy one will be sum; other ones could include md5, with more
available if openssl, gnupg, or pgp is
cases.
I think...
H
--
--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 16, 2003 at 04:45:09AM -0400, Harlan Stenn wrote:
I'm trying to find a way to have automake generate Makefiles
In this case, the subdir is another auto* package.
I *could* solve this by passing an argument to distcheck's configure , but
I didn't see how to do that, either.
Is there a way to pass configure options to distcheck's configure run?
H
--
Hi,
Harlan Stenn [EMAIL PROTECTED] writes:
I
I have a subroutine that is only conditionally built.
I have listed this subroutine in DIST_SUBDIRS, as that's where I gather the
list of subdirs that must be in a distribution but might not be built are
specified.
With 1.7.6, distcheck now fails as it tries to cd to this directory inside
the
Harlan Is there a way to pass configure options to distcheck's
Harlan configure run?
See DISTCHECK_CONFIGURE_FLAGS.
Thanks, and that doesn't work completely either.
(This is for ntp-dev, in case anybody is curious.)
Here's the drill. ntp now includes an optional (subdir) package, sntp.
I have an automake/autoconf package that builds normal software and also
kernel modules.
configure builds a default set of CFLAGS that gets used to build general
software.
The problem is that the Makefile.am for any kernel code needs to use
different CFLAGS, and when automake sees this we get
Thanks, if it comes down to it I'll put AUTOMAKE_OPTIONS=-Wno-gnu in the
affected Makefile.am's.
I'm trying hard to keep the warnings, as I want the developers to write
cleaner code...
H
I have a situation where I want every Makefile.am to 'include' one of
several files.
If none of these files are 'include'd I want the automake run to abort.
I know how to cause the abort at runtime, but I'd rather catch this problem
while automake is running.
Is there a way to do this?
H
I know this has been discussed before, and I don't remember seeing a good
solution. Perhaps this has changed with automake-1.7.7...
I have a situation where I am using automake conditionals to control the
installation directory of _PROGRAMS.
In certain configurations I want them to be
Did you mean autoconf 2.58? I don't see 2.59 anywhere...
And where is CVS automake these days? Is it still on sourceware.cygnus.com?
H
--
Harlan == Harlan Stenn [EMAIL PROTECTED] writes:
Harlan I know this has been discussed before, and I don't
Harlan remember seeing a good solution
ntp's util/Makefile.am has a line that looked something like:
bin_PROGRAMS = @A@ @B@ @C@
and was almost 80 characters long.
automake-1.7.7 (and 1.7.8, apparently) have a problem in that they wrap the
line (adding a \ continuation).
The problem is that if the conditional programs are not being
Is there an easy way (using automake) to have all of the built targets
depend on the Makefile, so whenever the Makefile changes everything
will get rebuilt?
H
The instructions say that automake 1.8 can be built with texinfo-4.0 or
later.
In my experience 4.0 doesn't do it, but 4.2 is OK.o
H
This change:
- Makefiles will prefer `mkdir -p' over mkinstalldirs if it is
available. This selection is achieved through the Makefile
variable $(mkdir_p) that is set by AM_INIT_AUTOMAKE to either
`mkdir -m 0755 -p --', `$(mkinstalldirs) -m 0755', or
`$(install_sh) -m 0755
Howdy Alexandre,
Happy new year.
Thanks, and same to you.
Harlan == Harlan Stenn [EMAIL PROTECTED] writes:
Harlan This change:
Harlan - Makefiles will prefer `mkdir -p' over mkinstalldirs if it is
Harlan available. This selection is achieved through the Makefile
Harlan variable
I'm looking for a fast fix to this problem, as it is the current sticking
point on a bunch of other changes I need to implement for a project.
I don't know if I'll have the time to implement the potential fixes
described in the bug report at this time, so I'm wondering if there may be
another way
[1] There are people who think a config.guess output that says:
i686-pc-linux-gnu
is normal, while some of us feel that is a particularly useless value a=
nd
would prefer to see something like:
i686-pc-redhat7.3
instead, just like the original documentation spec'd out.
Harlan Stenn wrote (meaning Linux distribution when he writes OS):
help tool maintainers make choices
about how things that are hard to find out otherwise (like OS-based
choices).
...
everybody who wants to make OS-level decisions has to code their own tests
to figure out the OS name
slows
progress toward the goal we both seem to have in common.
And N people writing N different autoconf macros does not do much to
advance the art.
H
--
Harlan Stenn wrote:
The differences between ALL of the various linux-gnu implementations are
so slight that they are far more suited
If there was a version number in the Vendor field I'd be lots happier.
In the RH distros I've seen (and the config.guess output on those boxes) I
have still only seen pc for the Vendor field.
H
--
On Tue, 2004-01-13 at 13:43, Bruno Haible wrote:
Harlan Stenn wrote:
If the releases
I think you are missing my point.
=20
The information I am talking about is used for *runtime* decisions - very
likely in a script that is in a shared directory used by many different
architectures.
Oh, well, config.guess isn't designed for that -- it's for compile time
decisions.
to go in my experience.
H
--
Harlan Stenn wrote:
If the releases are all that similar, why not use:
i686-GnuLinux-*
as your test, and provide the popular distributions in the 3rd field?
This is a little more reasonable, since it allows to check for Linux with
a single test
It is way to late to even think about changing things now.
It's never too late to improve software.
The amount of software that will be created from here on can be reasonably
expected to be MUCH greater than what has been written so far.
The change to, for example:
i686-DistroRev-linux-gnu
Thanks!
I'll do what I can. One problem is that this works for me in 108 other
Makefile.am's, and every once in a while one of them stops working and I
have to say where each source file lives.
It is strange...
H
--
Sorry for the delay.
Harlan == Harlan Stenn [EMAIL PROTECTED] writes
Be aware that += does not work with automake conditionals in several/many
cases until you get to at least 1.6.
H
We have a tree with over 1200 Makefile.am's.
Under automake-1.5 these files were processed in about 15 minutes on a
reasonably zippy machine.
Under 1.8 this takes over an hour and a half.
I first mentioned this in:
http://mail.gnu.org/archive/html/automake/2004-02/msg00058.html
which
Alexandre,
I am running different versions of automake against the code in question and
am getting Interesting results - sometimes automake-1.8.3 runs in 9-12
minutes, and sometimes it takes about an hour.
I'm trying to find a way to reliably duplicate each case.
I might have more results and
OK, I think I have something.
If AC_CONFIG_AUX_DIR is populated, automake runs in 9-15 minutes of
wall-clock time.
If it is not populated (except for ltmain.sh) then it takes 45 minutes to
run.
The items that end up in AC_CONFIG_AUX_DIR are:
compile* config.sub* install-sh* missing*
Folks,
I'm following up on the problem Asim Suter mentioned last October.
We are seeing problems where .Plo files get corrupted.
This has been happening with automake-1.5 thru 1.8.3, and autoconf-2.53 thru
2.59.
We have noticed this problem on RedHat 7.3 (probably earlier as well).
I think we
OK and thanks on all counts!
H
--
Harlan == Harlan Stenn [EMAIL PROTECTED] writes:
Harlan Just in case this was missed...
Thanks. (Actually it's easier for me if you send bug reports to
[EMAIL PROTECTED])
Harlan So I'm using AM_INIT_AUTOMAKE([-Werror]) and I notice
Just in case this was missed...
So I'm using AM_INIT_AUTOMAKE([-Werror]) and I notice this:
Edit Makefile.am bogusly
gmake
cd /sourceplace /bin/sh /sourceplace/config/missing --run automake-1.8 --foreign
libcdb/Makefile:global-vars.mk:libcdb/Makefile.in
libcdb/Makefile.am:27: AM_CFLAGS
1 - 100 of 233 matches
Mail list logo
