On 09/10/2014 03:24 AM, Dan Nicolaescu wrote:
Trying to add a target with
libexec_LIBRARIES
results in an error:
error: 'libexecdir' is not a legitimate directory for 'LIBRARIES'
But it looks like having libraries in libexec is something already in
use by a few things.
On a Fedora 20
On 02/24/2014 10:01 AM, Marco Maggi wrote:
Ciao,
I am moving a package that compiles many source files to
many binary files, from one Makefile.am per subdirectory
to a single top level Makefile.am. Most of the thing has
gone fine (excluding the tedium of rechecking all the search
On 02/24/2014 11:13 AM, Marco Maggi wrote:
Ralf Corsepius wrote:
Do I understand correctly, your issue is installation dirs?
In that case you can try to use a separate installation-dir
variable. something along the lines of:
mystuffdir =$(datadir)/stuff
datadir_stuff_DATA = lib/stuff/alpha.fasl
On 01/29/2014 06:10 AM, Pierre Phaneuf wrote:
I've just set up a Makefile.am for a package I'm working on, and it's going
pretty well, but I've hit a snag with cross-compilation...
This package installs a binary and a resource file. That resource file is
build with a special tool that is build
On 06/12/2013 12:25 PM, Stefano Lattarini wrote:
Thanks, this is exactly what I needed, and your diagnosis seems spot-on.
I will soon post a couple of patches that should first expose and then
fix the issue.
I gave your patches some life-testing - AFAICT so far, they seem to
resolve the issue.
On 06/05/2013 12:03 PM, Stefano Lattarini wrote:
[+cc bug-automake, so this will be registered in the bug tracker]
On 06/05/2013 07:16 AM, Ralf Corsepius wrote:
On 06/03/2013 09:14 PM, Stefano Lattarini wrote:
We are pleased to announce the GNU Automake 1.13.3 maintenance release.
When
On 06/03/2013 09:14 PM, Stefano Lattarini wrote:
We are pleased to announce the GNU Automake 1.13.3 maintenance release.
When comparing automake-1.13.2 generated Makefile.ins against
automake-1.13.3 generated Makefile.in, in projects which are _not_ using
c I am observing changes like this
On 10/23/2012 06:19 PM, Hartmut Holzgraefe wrote:
On 23.10.2012 18:05, Rudra Banerjee wrote:
I don't know if this is asking too much from autotools, but is it anyway
possible to install missing dependency files via autotools?
say, in my program, I use libsoup as
#include libsoup/soup.h
is it
On 10/03/2012 05:29 PM, Rudra Banerjee wrote:
Yes,
I got some site on non-recursive automake.
But I have one more queries: I have 100+ routine in src/.
Do I need to enter ALL of them manually as automake do not like
wildcards, or we have any shorter way?
Yes, but where is the problem? You can
On 08/21/2012 06:01 PM, Paolo Bonzini wrote:
Ok. So the question I'd like you to ask yourself are:
This needs to be done for each NG-NEWS items. It could improve the
existing users of Automake, and reduce the size of NG-NEWS. Both of
which are good things!
And I've done that already
On 08/21/2012 06:01 PM, Paolo Bonzini wrote:
Ok. So the question I'd like you to ask yourself are:
This needs to be done for each NG-NEWS items. It could improve the
existing users of Automake, and reduce the size of NG-NEWS. Both of
which are good things!
And I've done that already
On 08/08/2012 05:13 AM, Bob Friesenhahn wrote:
On Mon, 6 Aug 2012, Eric Blake wrote:
What _specific_ feature are you using from 1.12 that wasn't present in
1.11? Or put another way, either your configure.ac works equally well
with both versions (so you don't care which version), or there's
On 08/07/2012 08:16 AM, Miles Bader wrote:
Ralf Corsepius ralf.corsep...@googlemail.com writes:
My issue is ...rantrantblatherblather...
Please start a new thread when your message has bugger all to do with
the previous message.
Pardon, may-be I am missing something, but in my understanding I
On 08/07/2012 08:35 AM, Miles Bader wrote:
Ralf Corsepius ralf.corsep...@googlemail.com writes:
Pardon, may-be I am missing something, but in my understanding I am
having the same issue as the OP:
No, you were just looking for an excuse to start ranting...
Feel free to think so ... EOT
On 08/07/2012 01:36 AM, Eric Blake wrote:
On 08/06/2012 05:29 PM, Peter Johansson wrote:
Hi,
I'd like to distinguish automake 1.11 from 1.12 (or later) at autoconf
time. I wonder is there's any documented macro that was introduced in
1.12 that I could use to m4_ifdef?
If nothing else, the
On 07/03/2012 10:54 PM, Stefano Lattarini wrote:
On 07/02/2012 02:57 PM, Stefano Lattarini wrote:
On 07/02/2012 02:26 PM, Ralf Corsepius wrote:
On 06/30/2012 08:30 PM, Stefano Lattarini wrote:
Maintaining ACLOCAL_AMFLAGS in the Makefile.am to pass extra flags
to aclocal is (and have always
On 06/30/2012 08:30 PM, Stefano Lattarini wrote:
Maintaining ACLOCAL_AMFLAGS in the Makefile.am to pass extra flags
to aclocal is (and have always been) quite of an hack. For example,
autoreconf is forced to grep Makefile.am to honour those flags. But
this is a bad obsolescent behaviour; in
Hi,
With automake 1.11.4 it was possible to create empty directories this way:
Makefile.am:
mystatedir = $(pkglocalstatedir)
mystatedir_DATA =
With automake-1.11.4, this doesn't work anymore and silently breaks
existing Makefile.ams.
Ralf
On 04/24/2012 10:34 AM, Stefano Lattarini wrote:
tags 11323 notabug
close 11323
thanks
Hi Ralf.
On 04/24/2012 09:50 AM, Ralf Corsepius wrote:
Hi,
With automake 1.11.4 it was possible to create empty directories this way:
Makefile.am:
mystatedir = $(pkglocalstatedir)
mystatedir_DATA
On 04/24/2012 10:49 AM, Ralf Corsepius wrote:
On 04/24/2012 10:34 AM, Stefano Lattarini wrote:
http://savannah.gnu.org/forum/forum.php?forum_id=7175
See also:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11030
-EFAILMAINTAINER
a) This kind of changes is inappropriate within a release
Hi,
automake = 1.11.4 doesn't create $(datadir)/aclocal.
This cause aclocal to fail:
tar xvf automake-1.11.4.tar.xz
cd automake-1.11.4
configure --prefix=/tmp/foo
make
make install
Change to the source directory of an arbitrary automake-based package
and run
/tmp/foo/bin/aclocal
aclocal:
On 01/25/2012 09:40 AM, Stefano Lattarini wrote:
We are pleased to announce the Automake 1.11.2b test release.
New in 1.11.2b:
* WARNING: Future backward-incompatibilities!
Breaking backward compatiblity and removing features within a release
series (here automake-1.11) is a truely bad
On 01/18/2012 11:22 AM, Stefano Lattarini wrote:
As of 2012-01-17, according to Google codesarch, almost no active
package is using the 'multilib' feature offered by automake.
This is only partially correct. Multilibs are a compiler's feature (esp.
a GCC feature) and widely used in the
On 12/10/2011 08:03 PM, Stefano Lattarini wrote:
We are pleased to announce the Automake 1.11.1b test release.
Stefano,
Could you clarify, if this a pre-release/test-release of an upcoming
automake-1.11.2 or an upcoming automake-1.12 release?
Ralf
On 12/12/2011 11:17 AM, Stefano Lattarini wrote:
On Monday 12 December 2011, Ralf Corsepius wrote:
On 12/10/2011 08:03 PM, Stefano Lattarini wrote:
We are pleased to announce the Automake 1.11.1b test release.
Stefano,
Could you clarify, if this a pre-release/test-release of an upcoming
On 12/09/2011 02:21 PM, Jim Meyering wrote:
Hi Ralf, It sounds like you're confusing with build-from-release-tarball.
No, I am not.
There is a very long tradition of maintainer/developer build-from-VC
requiring more (and very recent) tools than usual.
No, this is not true. Probably all GNU
On 11/22/2011 04:50 PM, Bob Friesenhahn wrote:
On Tue, 22 Nov 2011, Stefano Lattarini wrote:
Which IMHO would be a killer benefit :-)
But now that I think about it, a GNU make-based rewrite might also offer
better extensibility (if we get the APIs right, that is), and that would
be a *great*
On 11/22/2011 06:04 PM, Stefano Lattarini wrote:
Hi Ralf.
On Tuesday 22 November 2011, Ralf Corsepius wrote:
On 11/22/2011 04:50 PM, Bob Friesenhahn wrote:
On Tue, 22 Nov 2011, Stefano Lattarini wrote:
Which IMHO would be a killer benefit :-)
But now that I think about it, a GNU make-based
On 11/22/2011 06:47 PM, Bob Friesenhahn wrote:
On Tue, 22 Nov 2011, Ralf Corsepius wrote:
Another question is if GNU make is really good enough to warrant this
sort of change.
Good point - gmake has a long history of hickups :-)
My question was not meant to imply that GNU make is riddled
On 06/15/2011 09:40 AM, Stefano Lattarini wrote:
On Tuesday 14 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Fri, Jun 10, 2011 at 05:33:39PM CEST:
I would suggest to at least discourage using this in the documentation.
... I agree, and I will make the change soon. Maybe I
On 06/15/2011 07:57 PM, Eric Blake wrote:
On 06/15/2011 11:31 AM, Ralf Corsepius wrote:
DISTCHECK_CONFIGURE_FLAGS is useful in situations when a plain
./configure is not meaningful to a source tree, i.e. when a
source-tree mandatorily requires some configuration argument.
Such a source-tree
On 06/15/2011 11:56 PM, Stefano Lattarini wrote:
On Wednesday 15 June 2011, Ralf Corsepius wrote:
In other words: IMO, automake is right in encouraging users to avod
DISTCHECK_CONFIGURE_FLAGS,
Actually, automake will discourage the use of AM_DISTCHECK_CONFIGURE_FLAGS
*by developers
On 03/22/2011 07:54 AM, Paul Elliott wrote:
I have a c library that currently uses an old style Makefile that I want to
convert to auto*tools.
One .c file is used as a .h file. That is, it is included by another .c file and
it should not be itself compiled. Why the author did this I do not
On 01/07/2011 07:53 PM, Ralf Wildenhues wrote:
Hello Ralf,
* Ralf Corsepius wrote on Fri, Jan 07, 2011 at 05:52:54PM CET:
On 01/07/2011 03:36 PM, Stefano Lattarini wrote:
Currently, automake is not smart enough to resolve variable expansions
in AM_YFLAGS (or foo_YFLAGS) when scanning them
On 01/04/2011 07:10 PM, Peter Rosin wrote:
Just a silly question since nothing else is happening, do you even have
$host-ar somewhere on your path?
Unless a binutils package maintainer applies dirty tricks, all binutils
cross-toolchains have one.
Ralf
On 01/05/2011 08:08 AM, Lyre wrote:
For example, I'm writing a lib named mylib. The library contain a .pc file:
instdir = ${libdir}/pkgconfig
inst_DATA = mylib.pc
And I want that *.so goes in /usr/lib/mylib/ and *.pc goes in
/usr/lib/pkgconfig/
./configure --libdir=/usr/lib/mylib will install
On 09/06/2010 05:18 PM, Stefano Lattarini wrote:
This is mostly a cosmetic/consistency patch. I hope you'll find it
worth applying nonetheless.
Regards,
Stefano
-*-*-
Internationalization tests: prefer `test ! -r' over `test ! -f'
test -r is non-portable.
Very old shells do not support
On 09/06/2010 07:51 PM, Ralf Wildenhues wrote:
Hello Ralf,
* Ralf Corsepius wrote on Mon, Sep 06, 2010 at 07:49:04PM CEST:
On 09/06/2010 05:18 PM, Stefano Lattarini wrote:
This is mostly a cosmetic/consistency patch. I hope you'll find it
worth applying nonetheless.
Internationalization
On 02/25/2010 06:16 AM, rrlangly wrote:
Does anyone have an idea as to why I'd get the following error when compiling
my program using autotools. This used to compile and run, then I added new
code and linked against a new library, and now I get this.
g++ -DHAVE_CONFIG_H -I. -I../../GXT/src
On 01/29/2010 09:05 AM, Joakim Tjernlund wrote:
Is there a reason why the install target doesn't respect make -s?
I would really like to see autotools and libtool respect make -s.
What for?
When a developer asks for a silent build in order to catch problems
all one should see is real
On 01/29/2010 09:35 AM, Joakim Tjernlund wrote:
Ralf Corsepiusrc040...@freenet.de wrote on 2010/01/29 09:21:46:
On 01/29/2010 09:05 AM, Joakim Tjernlund wrote:
Is there a reason why the install target doesn't respect make -s?
I would really like to see autotools and libtool respect
On 01/29/2010 11:17 AM, Alfred M. Szmidt wrote:
And there are many examples of the opposite where less verbose output
is useful,
Where? So far, I have only experienced the contrary.
automake already supports silent compilation.
Yes, some automake maintainers share your opinion. I believe
On 01/29/2010 02:05 PM, Steffen Dettmer wrote:
On Fri, Jan 29, 2010 at 9:21 AM, Ralf Corsepiusrc040...@freenet.de wrote:
Silent make rules are harmful:
- Bogus defines []
typically do not show up as compiler warnings or errors.
Could you please explain that?
Example: Compling a
On 01/29/2010 03:42 PM, Alfred M. Szmidt wrote:
On 01/29/2010 02:05 PM, Steffen Dettmer wrote:
On Fri, Jan 29, 2010 at 9:21 AM, Ralf Corsepiusrc040...@freenet.de
wrote:
Silent make rules are harmful:
- Bogus defines []
typically do not show up as
On 10/14/2009 06:55 PM, Bob Friesenhahn wrote:
On Wed, 14 Oct 2009, Ralf Wildenhues wrote:
Actually, complaining can indeed change the situation.
Exactly.
To put it bluntly, I find the situation automake as shifted itself to be
similar to this ole' joke:
Look Ma, I can ride my bike with
On 10/13/2009 04:49 PM, Bob Friesenhahn wrote:
On Tue, 13 Oct 2009, Ralf Corsepius wrote:
The problem is verifying correctness of building packages in batches.
i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in compiler
calls etc. for correctness
(NB: A package, which compiles
On 10/14/2009 02:58 AM, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Corsepius on 10/13/2009 9:20 AM:
What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?
Exactly this is the problem.
The problem isn't
On 10/12/2009 08:26 PM, William Tracy (wtracy) wrote:
Hello,
I'm trying to cross-compile a library that uses GNU Autotools (Google
Coredumper, to be specific) for PPC using the MontaVista tool chain. The
sequence of commands I'm following is:
$ ./configure --host=ppc CC=/path/to/gcc
On 10/06/2009 09:52 PM, Ralf Wildenhues wrote:
[ adding automake@ ]
Hello Ralf,
* Ralf Corsepius wrote on Tue, Oct 06, 2009 at 05:49:52PM CEST:
a) AM_SILENT_RULES are harmful (I know, you know that I think about
this (mal-) feature this way - Working around the issues they are
causing
Akim Demaille wrote:
Hi autofriends!
nobase_ is really a nice feature to cope with a structured hierarchy of
files. But it does not work well with packages that avoid recursive
Makefiles. In my case for instance, my package has a hierarchy of files
in $(top_srcdir)/include, but it has no
Ralf Wildenhues wrote:
* Ralf Corsepius wrote on Tue, Mar 17, 2009 at 12:08:44PM CET:
Allan Caffee wrote:
On Sun, 15 Mar 2009, Ralf Wildenhues wrote:
There is another downside: up to now, one could use something like
foo_DATA =
to let $(DESTDIR)$(foodir) be created
Ralf Wildenhues wrote:
* Ralf Corsepius wrote on Mon, Mar 09, 2009 at 03:57:58PM CET:
Jan Engelhardt wrote:
On Monday 2009-03-09 15:44, Ralf Corsepius wrote:
Ralf Wildenhues wrote:
For this patch, I'm unsure if we should even add it at all.
FWIW: I am opposed to it.
I suppose you
Jan Engelhardt wrote:
On Monday 2009-03-09 15:44, Ralf Corsepius wrote:
Ralf Wildenhues wrote:
For this patch, I'm unsure if we should even add it at all.
FWIW: I am opposed to it.
All this silencing stuff does is to add further potential sources of errors.
Which ones
Jan Engelhardt wrote:
On Monday 2009-03-09 15:57, Ralf Corsepius wrote:
For this patch, I'm unsure if we should even add it at all.
FWIW: I am opposed to it.
All this silencing stuff does is to add further potential sources of errors.
Which ones
Jan Engelhardt wrote:
On Monday 2009-03-09 16:10, Ralf Corsepius wrote:
For this patch, I'm unsure if we should even add it at all.
FWIW: I am opposed to it.
All this silencing stuff does is to add further potential sources of
errors.
Which ones, please
On Thu, 2008-11-27 at 10:55 +0100, Jim Meyering wrote:
On one hand, I like the idea of accommodating the rare srcdir `pwd` that
contains white space.
Pardon, but white spaces in arbitrary directories are fairly common on
Windows (My Files, Meine Dateien etc.) rsp. to users who migrate
their
On Mon, 2008-07-14 at 11:41 +0200, Klett, Stefan wrote:
Hi Ralf,
Thanks for your reply - I ve done what you told me - but now the error seems
to shift to the following (in config.log) :
configure:2783: checking for suffix of executables
configure:2790: g++ -o conftest -I -L conftest.cpp
On Tue, 2008-06-03 at 15:29 +0200, Jef Driesen wrote:
Ralf Wildenhues wrote:
* Jef Driesen wrote on Tue, Jun 03, 2008 at 12:31:29PM CEST:
CFLAGS=-I${includedir}
#include libfoo/header.h
or
CFLAGS=-I${includedir}/libfoo
#include header.h
[...]
It's purely a matter of
On Tue, 2008-05-27 at 12:09 +0200, Bernd Jendrissek wrote:
On Mon, May 26, 2008 at 9:29 PM, Ralf Wildenhues [EMAIL PROTECTED] wrote:
* Bernd Jendrissek wrote on Thu, May 08, 2008 at 09:41:36PM CEST:
On Wed, May 7, 2008 at 1:07 PM, John Darrington [EMAIL PROTECTED] wrote:
How can I change
On Mon, 2008-05-12 at 11:22 -0400, David Bruce wrote:
Hello,
If I understand correctly, MKDIR_P is recommended but requires
automake-1.10
or higher. Is this right?
Correct.
C.f. info Automake
If you are using Automake, there is normally no reason to call this
macro, because
On Tue, 2008-05-13 at 10:37 +0200, Stepan Kasal wrote:
Hello,
On Mon, 2008-05-12 at 11:22 -0400, David Bruce wrote:
MKDIR_P is recommended but requires automake-1.10 or higher. [...]
is there an acceptable workaround?
forgive me stating the obvious, but the workaround is to use
On Tue, 2008-05-13 at 07:55 -0400, David Bruce wrote:
Hi,
On Tuesday 13 May 2008 04:37:16 am Stepan Kasal wrote:
Hello,
On Mon, 2008-05-12 at 11:22 -0400, David Bruce wrote:
MKDIR_P is recommended but requires automake-1.10 or higher. [...]
is there an acceptable workaround?
On Sun, 2007-10-21 at 16:24 -0500, Bob Friesenhahn wrote:
On Sun, 21 Oct 2007, Benoit SIGOURE wrote:
On Oct 21, 2007, at 7:13 PM, NightStrike wrote:
If I wanted -pipe passed in to gcc all the time, do I put that in
AM_CPPFLAGS or AM_CFLAGS?
I usually do this in my configure.ac:
On Mon, 2007-09-24 at 10:09 -0400, Roberto Alejandro Espí Muñoz wrote:
I tried using the example shown on the reference document of automake
pertaining the use of per source compiling flags. For it I tried the
noinst_LIBRARIES for creating .a files enclosing my compiled object files
.o . For
On Mon, 2007-09-24 at 10:42 -0400, Roberto Alejandro Espí Muñoz wrote:
Ok, sorry about that, I tried to simplify the example. I really use
much more directories
elements =\
main.cpp
bin_PROGRAMS = programABC
programABC_SOURCES = \
$(elements)
programABC_LDADD
=
On Fri, 2007-09-21 at 19:11 +0200, Ralf Wildenhues wrote:
* Ralf Corsepius wrote on Fri, Sep 21, 2007 at 06:57:04PM CEST:
On Fri, 2007-09-21 at 16:10 +0200, Ralf Wildenhues wrote:
* Ralf Corsepius wrote on Thu, Sep 20, 2007 at 09:46:12AM CEST:
[...]
| Makefile.am:1: `libdir
On Wed, 2007-09-19 at 19:32 -0700, Poe wrote:
Hi,
I have a pre-built shared library (.so) that I want to distribute, and when
make install is executed I need it to be installed in the libdir along
with libraries that are built during the make process.
I've tried several ways of adding it
On Thu, 2007-09-20 at 10:05 +0200, Ralf Wildenhues wrote:
Hello,
* Ralf Corsepius wrote on Thu, Sep 20, 2007 at 09:46:12AM CEST:
On Wed, 2007-09-19 at 19:32 -0700, Poe wrote:
I have a pre-built shared library (.so) that I want to distribute, and
when
make install is executed I
On Wed, 2007-01-31 at 05:48 -0500, Jim wrote:
From the automake document, I'd infer that the following would work,
but it doesn't.
You'd better read once more ;)
cgi_libdir=$(libdir)/cgi-bin
cgi_libdir_SCRIPTS = confdata/index.cgi
Makefile.am:18: `cgi_libdir_SCRIPTS' is used but
On Mon, 2007-01-22 at 08:43 -0600, Jason Kraftcheck wrote:
Ralf Wildenhues wrote:
Hello Jason,
thanks for your work. While I'm not to judge this, and pretty
indifferent about it, a couple of question to clarify a bit:
* Jason Kraftcheck wrote on Thu, Jan 18, 2007 at 11:36:55PM CET:
On Sun, 2007-01-14 at 06:20 -0500, Thomas Dickey wrote:
On Sun, 14 Jan 2007, Ralf Corsepius wrote:
On Fri, 2007-01-12 at 11:28 -0600, Jason Kraftcheck wrote:
This makes it *very* easy to miss potential important compiler warnings
and such in all the noise.
I could not disagree more
On Fri, 2007-01-12 at 11:28 -0600, Jason Kraftcheck wrote:
Hi,
I'm working on moving an existing project to use autotools. One of the
issues that I've encountered is that the build process is very verbose.
Due to factors outside my control, the CPPFLAGS used for compiling contain
a very
On Sat, 2006-10-14 at 09:18 +0200, Ralf Wildenhues wrote:
[ Cc: automake-patches ]
* Ralf Corsepius wrote on Thu, Oct 12, 2006 at 06:36:12AM CEST:
On Wed, 2006-10-11 at 22:02 +0200, Thomas Schwinge wrote:
On Wed, Oct 11, 2006 at 10:12:33AM +0200, Ralf Corsepius wrote:
with automake
On Thu, 2006-10-12 at 00:05 +0200, Thomas Schwinge wrote:
Hello!
On Wed, Oct 11, 2006 at 05:48:12AM +0200, Ralf Corsepius wrote:
On Tue, 2006-10-10 at 16:15 +0200, Thomas Schwinge wrote:
On Sun, May 14, 2006 at 06:09:10AM +0200, Ralf Wildenhues wrote:
http://sources.redhat.com/cgi-bin
On Wed, 2006-10-11 at 22:02 +0200, Thomas Schwinge wrote:
Hello!
On Wed, Oct 11, 2006 at 10:12:33AM +0200, Ralf Corsepius wrote:
with automake-cvs/HEAD, and using *.S, CPPASCOMPILE doesn't apply
$(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) to its compilation rules.
It also doesn't for 1.9.6
On Wed, 2006-10-11 at 08:25 +0200, Ralf Wildenhues wrote:
* Ralf Corsepius wrote on Wed, Oct 11, 2006 at 05:49:00AM CEST:
On Tue, 2006-10-10 at 17:55 +0200, Thomas Schwinge wrote:
What's the deal with making Automake support dependency tracking for (pre
processed) Assembler files
On Wed, 2006-10-11 at 08:36 +0200, Ralf Wildenhues wrote:
Hello Ralf,
* Ralf Corsepius wrote on Wed, Oct 11, 2006 at 08:28:45AM CEST:
I know it's not implemented in automake-1.8/1.9, but I thought
this was fixed in HEAD;)
You were right though, sorry about that. Dependency tracking
On Wed, 2006-10-11 at 09:55 +0200, Ralf Wildenhues wrote:
* Ralf Corsepius wrote on Wed, Oct 11, 2006 at 08:52:42AM CEST:
OK, I just was about to try automake-CVS + autoconf-2.60 and now am
facing an issue with a package using subdir-objects and *_SOURCES
containing *.S + *.c
On Tue, 2006-10-10 at 16:15 +0200, Thomas Schwinge wrote:
[Cced to automake@gnu.org and bug-automake@gnu.org for further
discussion. Which list is appropriate here?]
automake, is the correct list. This is an automake issue.
Hello!
On Sun, May 14, 2006 at 06:09:10AM +0200, Ralf Wildenhues
On Tue, 2006-10-10 at 17:55 +0200, Thomas Schwinge wrote:
Hello!
What's the deal with making Automake support dependency tracking for (pre
processed) Assembler files (the .S ones)? I've seen some bits of
discussions about this in various places, but no final conclusion so far.
Check
On Tue, 2006-08-08 at 20:18 +0800, Tzu-Chien Chiu wrote:
Hello, Ralf.
I found gcc and newlib don't use AM_ENABLE_MULTILIB, instead
TARGET_SUBDIR is set.
Pardon, they (and binutils) use it.
AM_ENABLE_MULTILIB is used in library subdir configure scripts
(*/configure.[ac|in]), not inside of
On Thu, 2006-09-21 at 21:36 +0800, Tzu-Chien Chiu wrote:
Thank you. You're right. It has nothing to do with multilib.
I've read configure.ac and Makefile.am of texinfo.
I am not familiar with texinfo's sources
Here is how it works.
When cross-compiling, the same configure script is run
On Mon, 2006-07-03 at 10:27 +0530, Parag N(पराग़) wrote:
Hi,
I want to know for what -fno-unit-at-a-time is used? and whats
relation of this option with respect to current kernels/gcc3.4/gcc4?
Wrong list. Automake doesn't use -fno-unit-at-a-time.
Your question is a GCC question, not an
On Mon, 2006-07-03 at 11:01 +0530, Parag N(पराग़) wrote:
Hi,
On 7/3/06, Ralf Corsepius [EMAIL PROTECTED] wrote:
On Mon, 2006-07-03 at 10:27 +0530, Parag N(पराग़) wrote:
Hi,
I want to know for what -fno-unit-at-a-time is used? and whats
relation of this option with respect
On Mon, 2006-06-26 at 04:34 +, Harlan Stenn wrote:
We are told that we should not use CPPFLAGS or CFLAGS in a Makefile.am,
as they are for users.
That's only partially true.
More precisely: You should not override user-supplied CPPFLAGS, CFLAGS,
CXXFLAGS, LIBS etc.
Appending something to
On Mon, 2006-06-12 at 10:16 +0200, Norbert Sendetzky wrote:
Hi Ralf
Norbert Sendetzky wrote:
This works, but as soon as I move AM_CFLAGS to the Makefile.am in the
parent directory, they aren't set any more. Is this the way it was
intended and the only way to set them globally is
On Tue, 2006-06-06 at 08:29 +0200, Ralf Wildenhues wrote:
Hi Ralf,
* Ralf Corsepius wrote on Tue, Jun 06, 2006 at 05:44:00AM CEST:
On Mon, 2006-06-05 at 23:15 +0200, Ralf Wildenhues wrote:
GNU Autoconf test version 2.59d is now available.
This is a beta release, intended
On Tue, 2006-06-06 at 02:22 -0700, Paul Eggert wrote:
Ralf Corsepius [EMAIL PROTECTED] writes:
= If automake doesn't hold what it promises, it's a bug in automake
At the very least there is a documentation problem in Automake,
because nowhere does it say that you can't have a test named
On Mon, 2006-06-05 at 23:15 +0200, Ralf Wildenhues wrote:
GNU Autoconf test version 2.59d is now available.
This is a beta release, intended to be largely identical to 2.60,
to be released very soon, if no unexpected issues turn up. So test it
now, use it with your code, and report any
On Tue, 2006-05-30 at 12:23 -0500, Bob Friesenhahn wrote:
On Mon, 29 May 2006, Stefan Puiu wrote:
However, people haven't mentioned yet the main point in Peter Miller's
paper - dependency handling, which I think is very important
Well, that's one of those cases I'd prefer to call urban
On Fri, 2006-05-26 at 13:49 -0700, Tyler MacDonald wrote:
A lot of packages (libxml2, APR, gnome, etc) come with these -config
scripts that give you information like includes, libraries, etc... is there
some autoconf/automake/other magic i can use to automatically generate one
of these for my
On Wed, 2006-05-24 at 13:57 +0200, Ralf Wildenhues wrote:
Hi Olly,
* Olly Betts wrote on Wed, May 24, 2006 at 12:24:53PM CEST:
I've been looking at the feasibility of converting a project (Xapian)
using autoconf+automake+libtool to using non-recursive makefiles.
I'm fairly convinced
On Wed, 2006-05-24 at 17:01 +0200, Ralf Wildenhues wrote:
* Ralf Corsepius wrote on Wed, May 24, 2006 at 04:34:02PM CEST:
It often helps a lot to have fewer Makefiles than one per directory,
especially in parts of a source tree where they are rather simple.
- subdir makefile.am-fragments
On Sun, 2006-01-29 at 19:16 -0200, [EMAIL PROTECTED] wrote:
Hello
I am new to automake and stuff. I have read and copied several examples so as
to learn how to use it. There is one thing I couldn't find: a extremely
simple example on how to build a library.
Google for the goat book.
On Sun, 2006-01-15 at 21:21 +, Angus Leeming wrote:
Guys,
I'm having difficulty with the following set of files and compilation
requirements.
qdvi/
psheaders.txt \
squeeze.c \
psgs.cpp \
psgs.h
1 squeeze.c it to be compiled to
On Sun, 2006-01-15 at 12:09 -0500, Bob Rossi wrote:
On Sun, Jan 15, 2006 at 05:15:07PM +0100, Ralf Wildenhues wrote:
* Bob Rossi wrote on Sat, Jan 14, 2006 at 10:15:10PM CET:
I recently upgraded to a newer automake, and I started to get this
warning.
On Wed, 2006-01-11 at 16:10 +0100, Ralf Wildenhues wrote:
[ again, please follow up to automake@gnu.org only ]
* Matt Hull wrote on Wed, Jan 11, 2006 at 01:30:40AM CET:
icarus.cc.uic.edu/~mhull1/mine-0.0.9.tar.gz
This makes it much easier to see what is going wrong.
Try this as
On Mon, 2006-01-09 at 15:30 -0600, Matt Hull wrote:
makefile.am :
-
bin_PROGRAMS = mine
mine_SOURCES = src/main.c
if WITH_GTK1
mine_sources += src/gtk2/gtk1.c src/gtk2/gtk1.h
endif
DIST_SUBDIRS = src src/gtk1 src/gtk2
[EMAIL PROTECTED] ~/mine-0.0.9 $ aclocal -I
On Tue, 2006-01-10 at 12:16 -0600, Matt Hull wrote:
On Mon, 2006-01-09 at 15:30 -0600, Matt Hull wrote:
makefile.am :
-
bin_PROGRAMS = mine
mine_SOURCES = src/main.c
if WITH_GTK1
mine_sources += src/gtk2/gtk1.c src/gtk2/gtk1.h
endif
DIST_SUBDIRS =
On Tue, 2006-01-10 at 13:55 -0600, Matt Hull wrote:
On Tue, 10 Jan 2006, Ralf Corsepius wrote:
On Tue, 2006-01-10 at 12:16 -0600, Matt Hull wrote:
On Mon, 2006-01-09 at 15:30 -0600, Matt Hull wrote:
makefile.am :
-
bin_PROGRAMS = mine
mine_SOURCES
1 - 100 of 229 matches
Mail list logo
