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 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
pa
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 b
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
is it possible for a
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 e
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 whe
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
som
On 08/07/2012 08:35 AM, Miles Bader wrote:
Ralf Corsepius 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 08:16 AM, Miles Bader wrote:
Ralf Corsepius 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 am
having the same
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 aut
On 05/10/2012 09:14 PM, Paul Elliott wrote:
I want the people that receive my tarball to do autoreconf. Their system's
autoconf-archive may be more up-to date than mine.
This is a pretty questionable approach.
In particular, this way,
* you are forcing your users to install sufficiently compat
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: c
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 with
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_D
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 ide
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/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 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
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,
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 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 know
On 03/10/2011 01:03 PM, Roger Leigh wrote:
On Thu, Mar 10, 2011 at 11:38:16AM +0100, Vincent Torri wrote:
You also have to support static linking.
This is not meant to sound like a troll, but: is anyone really
*really* using static linking in 2011?
Yes. Some embedded systems for example do
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 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 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 -I.
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 Corsepius
wrote:
>> Silent make rules are harmful:
>> - Bogus defines []
>> typically do not show up
On 01/29/2010 02:05 PM, Steffen Dettmer wrote:
On Fri, Jan 29, 2010 at 9:21 AM, Ralf Corsepius 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 package under
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 thes
On 01/29/2010 09:35 AM, Joakim Tjernlund wrote:
Ralf Corsepius 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 ma
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 warning
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 t
On 10/14/2009 07:05 AM, Ralf Wildenhues wrote:
[ dropping autoconf@ ]
* Ralf Corsepius wrote on Tue, Oct 13, 2009 at 05:20:30PM CEST:
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" p
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&#
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, whic
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
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 CXX=/pa
Jim Meyering wrote:
I like automake's upcoming --silent-rules option enough
that I'm making it the default (when possible) for coreutils.
Well, if you think such a step to be helpful, I disagree.
Since I bootstrap using automake from its "next" branch, it's
enabled for me. And that translates
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 in
Andre Heine wrote:
Hi
Am Dienstag, 13. Januar 2009 18:27 schrieb Юрий Пухальский:
I'm sure that it will work, but to me it looks as hacky as the %option
approach. Shouldn't automake hide these nasty details from me?
IMHO, automake should recognize the suffix, i.e. "*.lpp" for flex c++
and
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
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
>
> or
>
> CFLAGS=-I${includedir}/libfoo
> #include
> > [...]
> >>> It's purely a
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
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 acce
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
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, be
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 con
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_L
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" .
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:
> [...
On Fri, 2007-09-21 at 16:10 +0200, Ralf Wildenhues wrote:
> Hello Ralf,
>
> * Ralf Corsepius wrote on Thu, Sep 20, 2007 at 10:50:09AM CEST:
> > On Thu, 2007-09-20 at 10:05 +0200, Ralf Wildenhues wrote:
> > > * Ralf Corsepius wrote on Thu, Sep 20,
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 distri
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 ad
On Fri, 2007-03-16 at 14:38 +0100, Stepan Kasal wrote:
> Hello,
> Another example: when I submitted a patch that removed Makefile.in
> from MAINTAINERCLEANFILES to HAL, I got told that using
> `maintainer-clean' to delete everything generated by autotools has
> become a ``common practice'':
> http
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 `cg
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
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 ve
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 Wilden
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
> >
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;)
>
> Y
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 t
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 aut
On Tue, 2006-10-10 at 16:15 +0200, Thomas Schwinge wrote:
> [Cced to and 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 wrote:
> > http://sources.redh
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 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 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 what
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-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 t
On Tue, 2006-06-06 at 14:00 +0200, Stepan Kasal wrote:
> Hello Paul and Ralves,
>
> the change discussed here was triggered by problems with Solaris'
> make.
>
> I agree that the Automake manual could mention this bad scenario,
> perhaps something like:
> ``Avoid files with names identical to she
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 n
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.
> > &
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 l
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 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 fo
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.
>
> > -
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 c
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 c
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.
> > >
> > > > config/readli
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 a
On Tue, 2006-01-10 at 14:49 -0600, Matt Hull wrote:
>
> On Tue, 10 Jan 2006, Ralf Corsepius wrote:
>
> > On Tue, 2006-01-10 at 13:55 -0600, Matt Hull wrote:
> > >
> > > On Tue, 10 Jan 2006, Ralf Corsepius wrote:
> > >
> > > > On Tue, 2006-01-
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:
> > > >
> > > > > makefi
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
> > > en
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 $ aclo
On Sat, 2006-01-07 at 15:55 -0600, Matt Hull wrote:
> is it possible to only have one top level makefile ?
In most cases, yes.
> will that work with
> make install, make clean, and make dist ?
If you write you Makefile.am to support it, yes,
Why are you asking?
Ralf
On Wed, 2006-01-04 at 16:34 -0600, Matt Hull wrote:
> thanks, i think i got that kinda working.
>
> but now its compiling out of order. i have src/main.c that calls the
> gtkmain() in src/gtk-2.0/gtkmain.c it tries to compile src/main.c first
> and fails.
Nope ...
> gcc -DHAVE_CONFIG_H -I. -I
On Fri, 2005-12-09 at 22:45 +0100, Baurzhan Ismagulov wrote:
> Hello Brendan,
>
> On Fri, Dec 09, 2005 at 04:18:10PM -0500, Jacobs, Brendan D. wrote:
> > We'd like to be able to do "make test" and
> > "make release", and have automake just make the make release libraries
> > and programs versus us
On Tue, 2005-11-08 at 14:10 +0100, Harald Dunkel wrote:
> Hi Ralf,
>
> Ralf Corsepius wrote:
> > On Tue, 2005-11-08 at 08:15 +0100, Harald Dunkel wrote:
> >
> >>Hi folks,
> >>
> >>I would like to build 32bit and 64bit libraries within the
> >
On Tue, 2005-11-08 at 08:15 +0100, Harald Dunkel wrote:
> Hi folks,
>
> I would like to build 32bit and 64bit libraries within the
> same Makefile.am. In the install directory tree the libs
> should get the same name, but the 64bit library is supposed
> to be installed in ${exec_prefix}/lib64, of
On Thu, 2005-10-27 at 08:29 +0800, Steven Woody wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2005-10-26 at 21:52 +0800, Steven Woody wrote:
> >> Stepan Kasal <[EMAIL PROTECTED]> writes:
> >>
> >> > Hello,
> >>
On Thu, 2005-10-27 at 08:28 +0800, Steven Woody wrote:
> Andreas Schwab <[EMAIL PROTECTED]> writes:
>
> > Ralf Corsepius <[EMAIL PROTECTED]> writes:
> >
> >> limits.h is a POSIX header. On linux it is supplied by GCC.
> >>
> >
On Wed, 2005-10-26 at 21:52 +0800, Steven Woody wrote:
> Stepan Kasal <[EMAIL PROTECTED]> writes:
>
> > Hello,
> >
> > On Tue, Oct 25, 2005 at 10:23:55PM +0800, Steven Woody wrote:
> >> #ifdef HAVE_LIMITS
> >
> > add line
> >
> > AC_CHECK_HEADERS([limits])
> >
> > to configure.ac (or configure.in)
On Thu, 2005-09-29 at 10:44 +0200, Harald Dunkel wrote:
> Sander Niemeijer wrote:
> >
> > On woensdag, sep 28, 2005, at 17:04 Europe/Amsterdam, Harald Dunkel wrote:
> >
> >>> autoconf sets CFLAGS/CXXFLAGS to "reasonable defaults", that's all. If
> >>> these defaults cause problems on your platfor
On Tue, 2005-09-27 at 12:53 +0200, Harald Dunkel wrote:
> Ralf Corsepius wrote:
> >
> > Nope. You don't seem to have understood how things are working:
> >
> > AM_CFLAGS/AM_CXXFLAGS are supposed to take flags having been specified
> > by a package's dev
On Tue, 2005-09-27 at 19:38 -0600, Brian wrote:
> We have several files which are not able to be optimized, and when our mac
> mini tries to build the project it chokes up when attempting to do so. It
> seems incorrect to say that the package developer is the least qualified to
> judge compiler fla
On Sun, 2005-09-25 at 08:03 +0200, Harald Dunkel wrote:
> Brian wrote:
> > I have a need to force three files to not be optimized. I've followed the
> > instructions in the manual for setting them up in their own library, and
> > then using LIBADD to combine it with the original library.
> >
> > I
On Fri, 2005-07-01 at 15:23 +0200, Ralf Wildenhues wrote:
> * Ralf Corsepius wrote on Fri, Jul 01, 2005 at 03:20:22PM CEST:
> > On Fri, 2005-07-01 at 14:33 +0200, Ralf Wildenhues wrote:
> > > * Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST:
> > > >
1 - 100 of 252 matches
Mail list logo
