[About GNU make]
GNU make is a basic component of the GNU system, actively maintained and
developed, well documented, and required by other very important projects
(Linux Kernel and Git DVCS, for example).
GNU make is very portable, easy to compile, and fully bootstrapping (its
Am 12.01.2011 19:01, schrieb Stefano Lattarini:
GNU make is a basic component of the GNU system, actively maintained and
GNU make is very portable, easy to compile, and fully bootstrapping
GNU make is the default make program on GNU/Linux (okay, we're in
GNU make is readily available in
Am 13.01.2011 19:50, schrieb Bob Friesenhahn:
On Thu, 13 Jan 2011, Guido Draheim wrote:
* ClearCase - ships clearmake integrated with the build systems.
and there are sure some other build systems that have a frontend to
the user allowing for makefiles as the backend.
FYI, ClearCase's
Hint: ALL my packages derive the version number at
configure time by reading an external file, e.g.
VERSION, xxxrpm.spec or the version repository. Everything
else is being hacked around whatever new pecularities
some autoconf/automake release may have. Whatever lifts
the requirement on hacking is
Stepan Kasal wrote:
Hello,
On Wed, May 24, 2006 at 03:17:23AM +0200, Guido Draheim wrote:
[...] I am making it up as a patch over standard 'aclocal' - it just
adds a few options that imitate automake options -a and -c.
the CVS version of aclocal has an option --install which is very
I did once use an 'acinclude' tool to help copying macros from my
personal ac-archive to the various projects. The name stems from
writing out to acinclude.m4. It was based on an old version of
'aclocal'. It had too much difference to care for an updated version.
In the meantime we find that
Ouch, just saw that You wrote the original csharpcomp.sh. Well,
just consider it as an update from a current project ;-)
Guido Draheim wrote:
Bruno Haible wrote:
Guido Draheim wrote:
create a .NET wrappers for the linux dvb kernel api. It does
work - getting libtool to compile a native
Bruno Haible wrote:
Guido Draheim wrote:
create a .NET wrappers for the linux dvb kernel api. It does
work - getting libtool to compile a native shared library
being called from a managed dll that imports symbols from it.
Which are the command lines that you use for doing this? I'd like
DIST_SUBDIRS = lib bin examples
SUBDIRS = lib bin @EXAMPLES@
Simon Perreault wrote:
Hi,
I have a question for which I haven't been able to find an answer on my own,
using the usual resources (manual, google, etc).
My project uses automake and I want to have a directory containing example
Patrick Guio wrote:
On Tue, 23 Mar 2004, Guido Draheim wrote:
What I mean by interact is that one package uses on another one :-)
I can give you an example. I have a package pack1 which I have encapsulated
in another one, pack2 (I mean that I have a subdirectory pack2 in pack1
Patrick Guio wrote:
On Mon, 22 Mar 2004, Guido Draheim wrote:
Patrick Guio wrote:
Dear all,
This is not really a bug but I wonder if you have any remedy to the
following problem. If you use autoconf/automake for several packages
which interact with each other and for each package you generate
Bob Friesenhahn wrote:
On Mon, 22 Dec 2003 [EMAIL PROTECTED] wrote:
However, if I want to build in a separate build tree (relying on
VPATH), then I try the following:
mkdir /build
cd /build
/test/configure
make
This attempts to build in this new /build directory, but during
compilation it
Tim Van Holder wrote:
platform dependent parts present in the .libs subdirectory.
(or _libs on platforms where filenames cannot start with a '.')
s|.libs|.libs/_libs|
:-)=)
btw, s|general concept|generalized concept| ?
-- guidohttp://AC-Archive.sf.net
Ralf Corsepius wrote:
On Wed, 2003-07-30 at 09:30, Guido Draheim wrote:
Just trying to get terminology to the point, note that developers
from other platforms will most probably have known the term
linker script, so let's expand on that knowledge without
driving away newbies.
FYI: I find
Ralf Corsepius wrote:
Hi,
Simple question: Does automake support filenames containing blanks?
I fear, the answer is no:
# cat Makefile.am:
data_DATA = foo\ 1
# make DESTDIR=/tmp install
..
/bin/sh ./mkinstalldirs /tmp/usr/local/share
mkdir -p -- /tmp/usr/local/share
/usr/bin/install -c -m
Ralf Corsepius wrote:
On Wed, 2003-07-23 at 09:39, Guido Draheim wrote:
Ralf Corsepius wrote:
Hi,
Simple question: Does automake support filenames containing blanks?
I fear, the answer is no:
# cat Makefile.am:
data_DATA = foo\ 1
# make DESTDIR=/tmp install
..
/bin/sh ./mkinstalldirs /tmp
Alexandre Duret-Lutz wrote:
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf Hi,
Ralf Simple question: Does automake support filenames containing blanks?
I guess nobody really bothered because Make itself uses blanks
as filename separators. '\ ' seems to be a GNU extension, does
Thomas E. Dickey schrieb:
On Fri, 4 Jul 2003, Peter Simons' Anti-Spam-Tool wrote:
- English -
Because I receive several dozen spam messages each day, I installed a
small tool that will defer incoming mail message if it comes from an
address it sees for the
Marcus Bjurman schrieb:
Hi,
My project (http://www.nongnu.org/gcmd/) consists of two parts. One shared library and one ordinary executable linked agains the library. The library gets built alright but when building the executable libtool doesn't respect the $prefix that was choosen at
install-data-local : check
That's the answer. In reality I have a last line in the configure.ac
that says echo '#' make make check make install - it does
remind a casual install-from-source guy to do a make check before
going to make install. 't works pretty well, since many do a simple
mousing
Dalibor Topic schrieb:
Hi,
I'd like to have automake generate man pages from a
texinfo file (or DocBook, or some other format) using
a suitable tool. How could that be achieved?
I don't know what that question is asking for
actually - suffix rules are written just like
in plain make, nothing
Harlan Stenn schrieb:
I submitted a patch to handle this a while ago. Don't know what happened to
it.
H
well, I think something like this needed in many places around,
it doesn't quite matter how it is called or how it works. If
the current patch proposal works, along with path-separator on
a
For one of my project there was a bug report regarding
the project.m4 file that is going to be installed. So
far I did just use $datadir/aclocal of course - as it
is uncertain whether some `aclocal --print-ac-dir`
can be written to. Using a prefix-related default
happens to be gnu-style anyway.
Rafael Laboissiere schrieb:
When I use the macro AC_CONFIG_HEADERS, automake includes a rule in
Makefile.in to rebuild config.h.in through autoheader. Now, I do not want
at all that this file gets touched by autoheader, even when I modifiy one of
its presumed dependencies aclocal.m4 and
Braden McDaniel schrieb:
Quoting Alexandre Duret-Lutz [EMAIL PROTECTED]:
Braden == Braden McDaniel [EMAIL PROTECTED] writes:
[...]
Braden I've reviewed 7.2 in the GNU Coding Standards, and it's
Braden not clear to me what you're referring to. Where exactly
Braden should I be looking?
The
William S Fulton schrieb:
Guido Draheim wrote:
William S Fulton schrieb:
I see that CXXFLAGS and AM_CXXFLAGS gets passed to the linker
($CXXLINK). This doesn't seem correct as the C++ flags aren't
necessarily appropriate for linking. This isn't consistent with the
per-program
Gav Wood schrieb:
hi,
sorry if this email is just me being ignorant but i can't find an easy way of
doing what i need - perhaps you could help.
i'm using automake for a project that implements a plugin system. it has a
small, non-installed cradle (example) program for testing the library that
jlm wrote:
I'm using automake version 1.5. I'm getting an error with automake, and
I can't figure out why. When I run automake, I get this error:
automake-1.5: configure.ac: `AM_INIT_AUTOMAKE' must be used
But I am using AM_INIT_AUTOMAKE, here's the top of my configure.ac file:
#Process this
Markus Werle wrote:
Hi!
Consider the following case:
File VeryImportant.C contains code that really needs some
optimization available. But all other files could (at least during development)
be compiled without optimization, for the sake of not drinking too much coffee
due to long compilation
Lukas Österreicher wrote:
One other thing I just found:
autotools-for-ac.2.13.lt.1.4.2.am.1.5-2sfnet.i586.rpm
depends on perl-base, which is a mandrake rpm.
This probably means that your tools are useless for
distributions other then mandrake - unless you know
a way how to fix that.
$ grep
Lukas Österreicher wrote:
Hi there.
I've been having trouble compiling software generated with automake 1.5 (or
whatever
except 1.4) on my redhat 7.2 system. I have tried upgrading to automake 1.5
but that doesnt work nicely - I have damaged my system that way, and i would
not be able to compile
This is an autoconf.at.gnu.org question...
Michael Lemke wrote:
Today I've been trying to learn automakeautoconf. Something I can't
figure out although it is the main reason I am investigating automake:
How do I set compiler flags based on the compiler? For example, g77
requires -fdollar-ok
Tom Lord wrote:
are already installed. Call this set the bootstrap packages.
Let's then formally identify a _subset_ of the bootstrap packages,
which are those GNU tools that other (non-bootstrap) GNU packages are
allowed to depend on for the build process. For example, GNU Make
would
Es schrieb Schleicher Ralph (LLI):
Waldemar Rosenbach [EMAIL PROTECTED] writes:
But what is the best way to deal with the platform depend stuff in the
interface?
A platform independent interface!
among the problems of ac_create_config_h:
* some ac-checks will check the compiler,
Es schrieb Robert Collins:
-Original Message-
From: Guido Draheim [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 26, 2002 8:57 PM
To: Robert Collins; [EMAIL PROTECTED]
Subject: Re: lex yacc with C++ projects
Es schrieb Robert Collins:
It would be nice to be able
Es schrieb Peter Eisentraut:
Akim Demaille writes:
What I'm doing now is buying my freedom. The freedom to extend
Autoconf without 1. requiring from the rest of the world that they
adjust their distclean rules, 2. requiring that Automake folks release
a newer Automake etc., not to
*RTFM*
xyzdir = ${prefix}/games/blabla/xyz
xyz_DATA = myfile.jpg yourfile.wav
EXTRA_DIST = ${xyz_DATA}
Es schrieb Sander van Geloven:
Hi,
Can anyone give me a simple example of how to add a directory called xyz with
data
files to an RPM. I'm using automake and suppose that I have to
oh, and don't forget to list the directory in the .spec file,
and otherwise, 'see you on news:alt.os.linux.mandrake
%files
%_prefix/games/blabla/xyz/*
Es schrieb Guido Draheim:
*RTFM*
xyzdir = ${prefix}/games/blabla/xyz
xyz_DATA = myfile.jpg yourfile.wav
EXTRA_DIST = ${xyz_DATA
I never had problems with letting header and source files
be in the same subdir which has the name of the project itself.
Instead it gets easier to build different-named subprojects
together at the same time. W.r.t. to a prodesk I'd simply
bind all *.h and *.c into a subdir prodesk/prodesk,
David Carter wrote:
I need to build a non-libtool dynamically-loaded library, on windows and on HP/UX,
from c++ sources.
This library needs to be built as foo.dll on windows, foo.so on HP/UX.
I don't think I can use libtool, since the resulting dll/so needs to be used by
use the easy way.
the maintanance problems of the hard way have no real benefit over doing
some renamings.
And if there are other reasons that you are not supposed to
rename something, well, then you could use the rename trick.
this is - you add the following two pattern rules to your
Hi Tim,
you do confuse me a bit - it seems as if you just missed the
target by micrometer, especially the middle one of your
examples looks very good
if MYCONDITIONAL
OPTIONAL = lotsasource.c lotsayacc.y
else
OPTIONAL=
endif
foo_SOURCES = $(REGULAR) $(OPTIONAL)
The only thing that
Martin Hollmichel wrote:
Hi all,
I think the great misunderstanding is that the autotools are
not targeting real multiplatform development, but Unix centric
distribution of (GNU) OpenSource Software.
well, they are not restricted to the *but* IMHO. They are
just not 100% ready-made
This is not restricted to borland compilers, there are quite
some C-compilers on unix-systems that quite some people like
to see supported, however most of the autotools developers
do live in a quite gnu'ish/gcc'ish environment, and every now
and then, a gmake'ish/gcc pecularity slips in that
hi everyone,
I am still trying to crosscompile a dll on linux with the new
autotools series. Currently I use cvs-autoconf, automake-1.4d
and libtool-1.4 on top of libsdl.org/Xmingw32 cross-tools.
I did just need to change a single line in ltmain.sh which
enabled me afterwards to actually
Alexandre Oliva wrote:
On Apr 26, 2001, Guido Draheim [EMAIL PROTECTED] wrote:
I did just need to change a single line in ltmain.sh which
enabled me afterwards to actually *build* a dll.
Looks like you were not using -no-undefined when creating the
library. This is required to build
Guido Draheim wrote:
from that I'd say libtool knows that CC has created a pfe.exe but
the automake-rules/vardefs expect a builddir/pfe.exe too. A copy
of builddir' pfe to pfe.exe does indeed work. Who's to blame,
libtool or automake?
It is libtool's fault - even that the final link-line
Alexandre Duret-Lutz wrote:
"Dean" == Dean Hoover [EMAIL PROTECTED] writes:
[...]
Dean Another thing you could do is make multiple build directories
Dean and always make in a certain way in them. In other words, you
Dean could:
Dean mkdir debug-build opt-build
Dean cd
48 matches
Mail list logo