Bob Friesenhahn wrote:
> Karl Berry wrote:
> > However, this seems like it would be fairly commonly useful and easy
> > enough to do in the canonical test-driver script. So, any chance of
> > adding it as a standard feature? Any reasonable way of enabling it would
> > be fine, e.g., a flag that
Hello Rudra,
Rudra Banerjee wrote:
I am a subscriber of this list, but there is no post delevered in my
account. I also get a automake bounce notice, as
Your membership in the mailing list Automake has been disabled due to
excessive bounces ...
I tried to reply the mail as directed on the
Ineiev wrote:
Russ Allbery wrote:
Another place where the default behavior frequently breaks is if one is
applying a patch to both the generated file and the source file, usually
because one explicitly *doesn't* want to re-run Automake (often because
there's some incompatibility with the
Russ Allbery wrote:
Bob Proulx writes:
But another question to ask is if that is the case why not simply touch
all of the files to the same time after the patching and before the
make? That also forces everything to appear up to date too and doesn't
need AM_MAINTAINER_MODE to be added
Pippijn van Steenhoven wrote:
I am root on my (Linux) system and I set the stack size to unlimited. The
libtool macro reported a few billion (or something other really large)
for maximum argument list length, bash also agreed (it easily executed
the distdir target when copied into a bash
Jason Sewall wrote:
I'm maintaining an autotools-configured project, and I've noticed that
the make install resulting from my build (on x86_64 arch, linux) puts
generated libraries in prefix/lib instead of prefix/lib64 - is there
something I should do differently, or is the the expected
Karl Berry wrote:
Sorry, I still do. I don't see that texinfo is doing anything different
than (say) coreutils, wrt help2man.
Coreutils includes a copy of help2man with the distribution image so
that it will always be available. Whether perl is available to run it
is another story.
Bob
Peter Simons wrote:
Bob Proulx writes:
This is a documented limitation. See the following reference.
http://www.gnu.org/software/automake/manual/html_node/limitations-on-file-names.html#limitations-on-file-names
I am sorry, but that page doesn't seem to mention this problem
Peter Simons wrote:
I just ran across an interesting problem with automake 1.10. Just unpack
any other build into a directory called, say /tmp/test automake, and
run it. In my particular case, the makefiles failed to call the local
copy of install-sh because of the blank. I checked my
Thomas Dickey wrote:
Bob Friesenhahn wrote:
These options only work with GCC. If the compiler is GCC you can use
them, otherwise skip them.
The Intel compiler recognizes -Wall and -Werror (but not -pedantic in
the version I have at hand).
The Intel compiler was actively trying to be
Ralf Wildenhues wrote:
For Emacs, all I know was that M-x compile did all that I ever needed.
But I'm sure it can be extended for unusual compiler output as well.
For emacs use M-x compile to build. The default compile command is
make but may be modified as desired. To walk through every
John Calcote wrote:
I love this format because warnings and errors are obvious, and yet
you get enough output per file to tell you that something's going
on.
To give you a different perspective, I *hate* that format because it
hides problems and *makes debugging harder*. I want to see exactly
Robert J. Hansen wrote:
John Calcote wrote:
Hmmm. I'd have to disagree here. I carefully consider every warning I
see, and evaluate whether or not it represents a real problem.
Yes. This strikes me as perfectly sane behavior.
I also agree with this. Using reasonable judgement is a good
Bob Proulx wrote:
A minor problem caused in commit 5c55fb1f.
Oops! Wrong list. Sorry about the noise. Ignore this here. You
will see it there!
Bob
Stefan Bienert wrote:
after an hour of searching, how am I supposed to invoke -lm -lz into
my compilation? The documentation states something about using LIBS as
a variable, autoconf also speaks of LIBS but nobody tells one what to
do with that variable.
LIBS is inherited from autoconf and
Hi Karl!
Karl Berry wrote:
I've been looking through the manuals and code, but not finding a
definitive answer: is there a canonical/recommended ordering of running
the autotools, including automake?
I really like the encapsulation offered by 'autoreconf'.
Bob
NightStrike wrote:
I meant more along the lines of, for instance in the gcc project,
there is 'make all-gcc, make all-gmp, make all-mpfr, etc.
Those are all custom local targets. The problem is the same as if I
were Bilbo asking, What do I have in my pocket? It could be
anything and not truly
Kamaljit Singh wrote:
I was hoping to create a src tree which would build automake1.9 and
automake-1.9 has been replaced with automake-1.10.1. You should use
the later version.
ftp://ftp.gnu.org/gnu/automake/automake-1.10.1.tar.gz
autoconf2.61 and install them in a central place. Writing a
Polarina wrote:
The automake and friends automatically licensed my code with GPLv2 (They
added the COPYING file with that license) when I wanted GPLv3. What
gives? I'm using version 1.10.
$ automake --add-missing --copy
At the time that automake-1.10 was released GPLv2 was the appropriate
NightStrike wrote:
When you do make a release, where will be the list of new features located?
The NEWS file is the standard location to list new features.
The NEWS file as currently in version control can be seen here:
http://git.sv.gnu.org/gitweb/?p=automake.git;a=blob;f=NEWS;hb=HEAD
Bob
Sebastian Pipping wrote:
Thanks for your replies! As I understood the Automake
release is delayed because its licensing info has not
been updated to GPLv3 yet?
Actually the reverse. Because the licensing has already been updated
it is now delayed. Automake installs auxiliary files into your
Hongliang Wang wrote:
My company decides to make part of our software source code
open-sourced. For this part, we will use automake autoconf tools
to generate the installation package (.tar.gz).
That sounds wonderful!
However, the current problem is that we cannot decide what to check
Ralf Wildenhues wrote:
Agreed. Thanks. I've applied the patch below.
Thanks!
HP-UX 10.20 - - +
HP-UX 11.23 - - +
This really confused me because I was getting color. So I went back
and looked at things closely and I realized why. Quite some years ago
I
Ralf Wildenhues wrote:
Agreed. Thanks. I've applied the patch below.
Thanks!
HP-UX 10.20 - - +
HP-UX 11.23 - - +
This really confused me because I was getting color. So I went back
and looked at things closely and I realized why. Quite some years ago
I
Ralf Wildenhues wrote:
Ahh. More head scratching. I'd appreciate if somebody could
look over these two proposed patches to see if what I think how
signals ought to work makes sense.
This one I think is the opposite of what it needs to be.
+trap '' $signal
I think that should be trap -
Ralf Wildenhues wrote:
+case $TERM in
+dumb) exit 77;;
+esac
...
Thanks! Do we need to guard against other TERM settings, too?
Hmm... I was thinking more along the lines of this patch instead. I
don't think the test should be skipped. I think it should be made
independent of the invoking
This following automake 'make check' finishes successfully.
env TERM=ansi make -C tests check TESTS=color.test
However this next one has a failure.
env TERM=dumb make -C tests check TESTS=color.test
And this one is quite colorful! :-)
env TERM=dumb VERBOSE=yes make -C tests check
Ralf Wildenhues wrote:
- with TERM=vt100, on my GNU/Linux system there are still colors
generated by tput, so I did not use that TERM setting,
That is discouraging. The vt100 does not support color and tput
should not produce escape sequences for it. I believe that would
indicate a bug in
Please CC me since I don't normally read automake-patches. Thanks.
Ralf Wildenhues wrote:
Does anybody know how to test that colorful output actually happens?
Since the colorful output of check.mk now uses 'tput' and 'tput' uses
TERM, it should be sufficient to force TERM and then test the
Jason Curl wrote:
Continuing with my efforts of making a library designed for Linux a bit
usable for colleagues on Windows I'd like to figure out how to install
cat pages, i.e. conversions of man pages.
Hmm... Would it make more sense to set up 'man' on ms-windows for
your colleagues such
James Willenbring wrote:
Some of our developers find it especially painful to list individual files.
Is there any way that we can add all files with a certain suffix to the list
of files that are included in our distribution by default, or even include
files that match some pattern?
The
Jan Engelhardt wrote:
is there any real difference between $(var) and ${var}, and is the
latter as much POSIX as the first?
Is there any reason not to use $(var) and simply play it safe since
that is the traditional Unix make behavior? Then all worries about
whether the builder's make will
Ralf Wildenhues wrote:
* Roberto Alejandro Espí Muñoz wrote:
AC_INIT([/src/main.cpp])
Also note that there is a new form of AC_INIT/AM_INIT_AUTOMAKE,
used and explained in the manual:
http://sources.redhat.com/automake/automake.html#Hello-World
To give an example, try using this instead of
Sergey Poznyakoff wrote:
Ralf Wildenhues ha escrit:
Can s/yy/.../ change anything unintended? E.g., do we need to ensure it
only changes words beginning with yy?
In theory it could, for example if the programmer used identifiers
beginning with, or containing `yy'. However, I can hardly
Søren Boll Overgaard wrote:
Hello,
I've recently migrated a rather large body of code from a proprietary
development environment, to an automake based one.
I've run into trouble during linking though. The code is laid out like
this:
src/
Contains main.cpp which holds the main
antoon wrote:
By default this library is placed in the same directory as the C-files.
After the result of 'make' yes.
But ... how to copy this library afterwards to a general *lib* directory,
because during the overall linkage step of my code, I want all my libraries
in one single
Perrog wrote:
2007/2/28, Bob Proulx [EMAIL PROTECTED]:
I would really like a clean target that would remove generated source
files such as generated .c and .h files. In the case of yacc and lex
I would like to distribute the generated files so as not to require
the use of yacc and lex
Ralf Wildenhues wrote:
* Bob Proulx wrote on Thu, Mar 01, 2007 at 05:37:56PM CET:
With a use model more like this somewhat stylized example.
[...]
...modify code generator...
make moreclean
make
Looks to me like if your generated code had proper dependencies you
would not need
I would really like a clean target that would remove generated source
files such as generated .c and .h files. In the case of yacc and lex
I would like to distribute the generated files so as not to require
the use of yacc and lex to compile the distribution. This rules out
DISTCLEANFILES or
deckrider wrote:
Is there a best practice example for using autoconf/automake to
install system init scripts? For instance, HP-UX looks for these in
/sbin/init.d and /sbin/rc*.d and many others look to /etc/init.d and
/etc/rc*.d.
I would recommend not using automake for this. The format of
Mike Owens wrote:
Ralf Wildenhues wrote:
Mike Owens wrote:
I am maintaining my copy of automake in a subversion vendor branch. I
have encountered a problem that is very difficult for me to diagnose.
The copy in subversion will not build on Solaris. The tarball will.
That's probably
Jim Lynch wrote:
I'd really like a way to enable this for specific applications, not
as a site default. ... ... ... If not, I'll just have to go back to
my cludgy way of adding my own rules to copy it to a hard coded
/etc, (Ugh).
What I do is to keep a configure.sh script in the parent
Nicolas Joly wrote:
Bob Proulx wrote:
What is the best practice for organizing a program that includes
multiple lex generated scanners?
I encountered the same problem ... and made the following constructs
that did the trick (at least for me).
AUTOMAKE_OPTIONS = subdir-objects
Multiple flex generated scanners are giving me trouble with duplicate
symbols. I am using automake-1.10.
What is the best practice for organizing a program that includes
multiple lex generated scanners?
I am using the recommended practice of using defines to rename all of
the yacc/lex symbols
Jason Kraftcheck wrote:
This makes it *very* easy to miss potential important compiler warnings
and such in all the noise.
I have heard this infrequently from posters but I don't experience
this myself and here is why. I think I will go out on a limb and say
that most (many?) developers use
Dan McMahill wrote:
Ralf Wildenhues wrote:
Just curious: what's the reason for the ordering constraint?
When static objects use inheritance, the base class must be initialized
before anything can be derived from it. At least that's what I've been
told. On this particular project, I'm
Benoit Perrot wrote:
On debian, several version of the same package may be installed,
and the default, prefered one is selected by providing a
symbolic link pointing to it.
Yes. Very nice.
So, I was wondering if there was a way to select the automake
path or exe to use, or if patching
Mike Melanson wrote:
Sounds like a useful possible solution. However, what if the primary
functionality actually resides in a shared library itself?
As shown by ldd on the shared library? Those will be loaded using
LD_LIBRARY_PATH so in that case you don't need the complicated wrapper
for
Mike Melanson wrote:
It's possible that I'm chasing after the wrong solution. This is a more
specific problem:
* I have a proprietary program that I am trying to build to run on a
wide variety of Linux/x86-based distributions.
* The build process links against libstdc++.so.6 on the
Ralf Wildenhues wrote:
* Ed Hartnett wrote:
Ralf Wildenhues writes:
It's safe to just replace the two files with newer versions; I think you
should keep the two in sync though.
I thought I would note that both Debian and Red Hat packaging of
programs that use config.guess and config.sub
Bob Friesenhahn wrote:
It may be considered a good thing to some, but it is not necessarily a
good thing. Consider that the rest of the build package (e.g.
libtool) is expecting particular host identifications and that
sometimes the behavior of these scripts change.
Only very rarely will
Hi Ralf,
Ralf Wildenhues wrote:
Do
cd tests
env VERBOSE=x TESTS=acloca17.test java.test missing.test \
missing2.test obsolete.test make -e check
Here is the output from the current automake-1.9.6. One issue might
be my version of GNU m4-1.4. I need to update it too. Actually
Ralf Wildenhues wrote:
Tyler MacDonald writes:
OK, so I might need something more portable than cpio... but the
\s.* part does serve a purpose; the MANIFEST file format allows for a
description of the file after whitespace. I guess I could do [ \t] or
something else instead of the \s.
Hi Ralf,
Ralf Wildenhues wrote:
Hi Bob,
* Bob Proulx wrote on Sun, Apr 23, 2006 at 05:35:23PM CEST:
If you consider POSIX systems as being portable enough then using
the [:space:] character class should work pretty well.
Thanks to Mr. Solaris, no, I don't consider that portable
Noah Misch wrote:
Alexandre Duret-Lutz wrote:
I'm leery of assuming that Autoconf's version will always be at
this spot in the output of --version. Sometimes people customize their
copy and tweak --version to reflect so:
...
% gcc --version
gcc (GCC) 4.0.3 (Debian 4.0.3-1)
With
Ed Hartnett wrote:
To accommodate this on machines with disk quotas, I want to allow the
user to specify to configure a directory in which large files can be
created during testing.
You might look into just having the user set TMPDIR (or through your
configure option) to the directory for
Ralf Wildenhues wrote:
* Guillaume Rousse wrote:
Am i supposed to manually set libdir according to build host to get
compliance with such constraint ?
Yes, you can specify --libdir at configure time. Note for system
installations you will usually have to set more options, for
example
Harald Dunkel wrote:
Question about make depend:
If I set
SRCDIR = ../src
noinst_PROGRAMS = hello
hello_SOURCES = ${SRCDIR}/hello.c
Shouldn't you be using normal VPATH? That is, you are setting
hello_SOURCES = ../src/hello.c. But I don't think you want to do
that.
Kendrick Smith wrote:
Can anyone tell me why an Automake-generated Makefile
would rerun the 'configure' script when 'make' is invoked,
This would mean that the timestamps on the files indicate that you
have modified a source file such as modifying a Makefile.am. Because
the Makefile.am is
Brian wrote:
I wanted to be a little more clear on this (since you brought up the idea of
subdirectories I have become keen on it)
Actually it was you who brought up the question of did it work in
subdirectories.
Suppose I wanted to make two versions of hello - one in /src/hello and one
in
Brian wrote:
I am in the planning stages of autoconfiscating a large project. The project
will have a top-level makefile.am http://makefile.am and then several
Did you expect that to be a http web link?
subdirectories which each generate an executeable and have a
Stepan Kasal wrote:
Makefile.am contains:
foo.h: foo.x
$(GENERATOR) foo.x foo.h
But the GENERATOR command failed and I have empty foo.h.
Yes, because the shell redirection creates the file instead of the
generator.
It would be nice if make deleted foo.h automatically, but this is
Oliver Boris Fischer wrote:
my project contains of some bison and flex files. It seems so, that
automake will distribute the genrated c files.
Is this intended? How can I turn this off without abusing CLEAN_FILES
and co?
Yes, that is intentional. The documentation for automake says:
Jean-Denis Giguere wrote:
pymod/Makefile.am:4: `_gtkmissing.la' is not a standard libtool library name
[...]
The pygtk-2.4.0 use this kind of configuration and it works well.
I would really appreciate if someone may point me a document where I can
find more informations about this problem.
In this case I looked at the list of people in the discussion, knew
they were all subscribed, and intentionally mailed only to the list. ;-)
Andreas Schwab wrote:
Ralf Wildenhues [EMAIL PROTECTED] writes:
This is not addressed at me, but I also had to learn the hard way
that
- some gnu.org
Here is a message I recently sent to an individual after observing
that they never CC'd the original poster. This seemed topical after
reading today's discussion.
Bob
Thanks very much for answering questions on the mailing lists. It
is appreciated. However I noticed today that you have not
Alexandre Duret-Lutz wrote:
Please do direct bug reports to [EMAIL PROTECTED], a spurious
failure of CVS Automake is noise for [EMAIL PROTECTED]
There is no mention of bug-automake on the web page.
http://www.gnu.org/software/automake/
Could one be added? Here is a proposed patch against
r43233 wrote:
I have subscribed to the list but can't login. I have registered and
recieved confimation. However during confirmation i forgot to enable
cookies and the system won't allow me to login. I have enabled cookies
and exited mozilla and restarted it but still can't login.
regards
Gustavo A. Baratto wrote:
Basically, what I looking for is a 'make package' rule, where all
the files that would be installed, plus an install script could be
tarred up together, so we can copy the tarball to many diferent
servers, unpack it, run the script, and the files get installed
Jay West wrote:
You should have sent this to the list owner/admin, not the list.
Yes. But the list owner for the automake list is gnulists-ownrr at
gnu.org, which is to say, effectively nobody. The list is really
running entirely on inertia. For example there are over a hundred
messages in
Alexandre Duret-Lutz wrote:
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf On Mon, 2004-05-03 at 06:52, Bob Proulx wrote:
Older versions of automake allowed arbitrary library names.
noinst_LIBRARIES = foo.a
Recent versions of automake now complain about this naming
Dale E Martin wrote:
Bob Proulx wrote:
Makefile.am:2: `foo.a' is not a standard library name
Does this work?
foo_a_LDFLAGS=-module
No. I get the same result. I am glad it did not work. It would have
been just too strange. Thanks for making the suggestion just the
same.
Bob
Older versions of automake allowed arbitrary library names.
noinst_LIBRARIES = foo.a
Recent versions of automake now complain about this naming.
Makefile.am:2: `foo.a' is not a standard library name
I would normally like the lib naming but in this case I am retrofiting
an existing project
Priit Voolaid wrote:
i don't know is this the right place to ask my question. If not, sorry.
[EMAIL PROTECTED] would have been better than [EMAIL PROTECTED] This
has little to do with automake.
I want all the necessery files to go in /opt directory, so i execute
configure with --prefix=/opt.
Alexandre Duret-Lutz wrote:
Perl 5.005_03 will be 5 years old next month, and supporting it
is becoming painful.
I sympathize. But actually the problem is not the age of the old
version of perl is but rather youth of the new version. The new
version has not yet propagated yet. But let me
Yanfeng Zheng wrote:
There was a problem when i compiled my program on red hat linux
8.0. The error message was that the header file stdsyms.h was
needed. Where can i get stdsyms.h file? Thanks a lot.
Your question has nothing to do with automake. Why ask it here?
There is no standard header
Harlan Stenn wrote:
I think you are missing my point.
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.
If for use at runtime then config.guess is very poorly suited. Do you
Alexandre Duret-Lutz wrote:
Charles Wilson writes:
Chuck What is this Autoconf 2.59 of which you speak? I saw this
I'm using the AUTOCONF-2_59 tag from CVS. I didn't know it
hasn't been announced yet. All I can say is that Akim is away
today and tomorrow, so you'll have to wait if you
I am autoconfiscating a moderately large legacy project. A previously
existing methodology in the project is to create a large number of .c
and .h files by generating them with a script from a template. I have
created custom rules to do this and all builds fine. I originally put
the generated
Paul Brook wrote:
I have been thinking I should put the generated .c and .h files into
both EXTRA_DIST and MAINTAINERCLEANFILES.
Putting the files into BUILT_SOURCES should do what you want. This includes
them in the distribution, and removes them when you do make
maintainer-clean
Simon Richter wrote:
$(SHELL) your script here ?
[Drifting off topic...]
Does that mean that a SHELL=/bin/csh user will run the script with csh
and a SHELL=/bin/zsh user will run the shell with zsh? Wouldn't it be
better to use a predictable and most likely a standard shell for both
users?
Earnie Boyd [EMAIL PROTECTED] [2002-11-07 11:39:37 -0500]:
[EMAIL PROTECTED] wrote:
Otherwise, I'm also subscribed on the list, so no need to CC me in every
post :-)
Then set M-F-T in your postings.
Mail-Followup-To: [EMAIL PROTECTED]
It is a function of the mail client Reply-All event to
Lars Hecking [EMAIL PROTECTED] [2002-10-30 10:36:09 +]:
Well, I'm using AC_PATH_X but I don't know how to use this in the
Makefile.am , I have tried to get it to work with :
LDADD = -lX11 -lm -L$(x_libraries)
For one thing you need to place all of your -L options before your
Lars Segerlund [EMAIL PROTECTED] [2002-10-28 17:14:18 +0100]:
I'm just starting to use gnu autotools, and I have some small
problems, I have figured out how to build in some subdirs and to
have resonable include paths, but how do I link with X11 , I'm using
automake and autoconf and have a
I am wanting to use help2man to produce the man page for a program. I
have a Makefile.am with the following.
dist_man_MANS = example.8
example.8: src/example
help2man --output=example.8 ./src/example
But when I run 'make distcheck' I get the following error.
Error: files left
Bruce Korb [EMAIL PROTECTED] [2002-08-19 13:51:40 -0700]:
Do you distribute example.8?
I could go either way. Let's say no.
If not, add it to the DISTCLEANFILES,
That worked! Thanks!
So now my Makefile.am looks like this. Anything flagrantly wrong?
Otherwise this is working for me.
Random thoughts on version numbers...
to do this with automake since I've been saying for a long time 1.5
will do this, 1.5 will do that. Bleah, my bad.
Agreed. Buuut... 1.4a-p1 seems wrong if HEAD is at 1.4c. Worse, releasing
1.4b-p1 sounds like it is related to 1.4b. I still don't
pping for
the night and wanted to report this minor problem. This appears to be
a spurious result as to all other intents and purposes everything
configures and works well from this point on.
BTW... I like the new dependency code! I can now swap between HP-UX
ANSI C and Linux GCC interchangeably.
Bob Proulx
88 matches
Mail list logo
