[EMAIL PROTECTED] writes:
Thanks for the info. I really appreciate it. What is the easiest way
then to tell system to go to a different directory to build a dependency
if it is not built yet??
Either by having the SUBDIRS done in the right order as Alexandre
already mentioned, or adding
Jose Roman Bilbao [EMAIL PROTECTED] writes:
1st: I have a multiple subdirectories project. One of those directories
stores again multiple subdirectories. In each of them a librtary
(shared) is built and stored in .lib (local) directory. Te thing is that
I would like all my libraries to be
D H [EMAIL PROTECTED] writes:
It looks like the libs.am is setting AR = ar (I am
using version 1.5 of automake). This eventrually gets
inserted in Makefile.in, when libraries are being
created. This seems to override any other
initialization done by the user for AR.
make AR=my-ar should just
Joel Apter [EMAIL PROTECTED] writes:
matter). Would a simple configure, make, make install be all that is
necessary for both automake and autoconf (autoconf before automake
since it appears that autoconf 2.54+ is required to install automake
1.7.5). Thank you for your time.
Yes. And then
Davy Durham [EMAIL PROTECTED] writes:
These files are listed in the DIST_COMMON (at least I'm pretty sure
DIST_COMMON is where these files are coming from in the cp commands)
so I'm not explicitly listing them myself anywhere to be distributed.
I've tried several versions between and including
[EMAIL PROTECTED] writes:
I would have preferred that build system would see
myprogram_DEPENDENCIES = libmylibrary.a
and automatically known to build library FIRST.
Why don't you use myprogram_LDADD = libmylibrary.a ?
I'm not able to reproduce your problem. Can you tell us what
[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] newstream]# automake
aclocal.m4:1380: error: m4_defn: undefined macro: _m4_divert_diversion
autoconf/functions.m4:1277: AM_FUNC_OBSTACK is expanded from...
aclocal.m4:1380: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
[EMAIL PROTECTED] writes:
aclocal: configure.ac: 66: macro `AM_DISABLE_STATIC' not found in library
This error is usually caused by not having installed the libtool at
the same prefix as automake.
aclocal.m4:1380: error: m4_defn: undefined macro: _m4_divert_diversion
Robin Rowe [EMAIL PROTECTED] writes:
Hi. I have a shared library libfoo (in directory foo) that had some of its
source files moved (into subdirectory foo/bar) to help make the code easier
to manage. However, I'm having trouble linking libbar back into libfoo. Both
libfoo and libbar build ok.
Mattias Brändström [EMAIL PROTECTED] writes:
AC_INIT(foo.cpp)
AM_INIT_AUTOMAKE(foo, 0.1)
AC_CANONICAL_TARGET
AC_OUTPUT(Makefile)
I still get the same warning. Any ideas?
AM_INIT_AUTOMAKE calls AC_ARG_PROGRAM which should get called after
AC_CANONICAL_TARGET, so just changing the
Ehud Shabtai [EMAIL PROTECTED] writes:
My project has some include files which has ':' in its path. I.E. some
C source files has #include :pt:/inc/c.h.
The automatic dependencies which are generated includes these header files
and the ':' of the patch causes automake to think that there are
Mattias Brändström [EMAIL PROTECTED] writes:
dnl Check for SDL
SDL_VERSION=1.2.0
AM_PATH_SDL($SDL_VERSION,
:,
AC_MSG_ERROR([*** SDL version $SDL_VERSION not found!])
)
CFLAGS=$CFLAGS $SDL_CFLAGS
LIBS=$LIBS $SDL_LIBS
This is all well and good and I think this will
Stephen Torri [EMAIL PROTECTED] writes:
I am on a project that would like to only install shared library files
(.so) but not the .la files. I tried to put AC_DISABLED_STATIC and then
AM_DISABLED_STATIC into the configure to do this. Neither declaration
worked. Is there a method for doing what
These files are maintained by [EMAIL PROTECTED], I've added a CC:
to that.
/assar
Tomas Berndtsson [EMAIL PROTECTED] writes:
For the MiNT system, the lines in config.sub are wrong. It's missing
the '*'-wildcard. I've applied a patch below.
Greetings,
Tomas
---
Ossama Othman [EMAIL PROTECTED] writes:
If the macros placed in the package specific config.h are named so
that they are specific to the given package then why is installing
that header a problem.
I would agree with Gary here that the symptom is installing the
config.h (or whatever it's
Hi, Ossama.
Ossama Othman [EMAIL PROTECTED] writes:
However, sometimes this can't be avoided in the case of inlined
functions (e.g. C++). It isn't always feasible, particularly in
terms of performance, to always keep function implementations hidden
within the library. One could argue that
Robert Boehne [EMAIL PROTECTED] writes:
I have a massive set of C++ libraries that use
CVS libtool, autoconf and automake to build and install.
Since users then need to have _all_ the header files
they also need to have the configure generated config.h
What is the "best" way to coerce
Peter Williams [EMAIL PROTECTED] writes:
So if we expect the user to have the tool, put them in $builddir, and if
not, put them in $srcdir?
Basically, yes.
Will automake find the built sources if I put them in $srcdir?
Yeah, it should just use vpath.
Cause rightnow, when I build Balsa
Peter Williams [EMAIL PROTECTED] writes:
Do built sources go in $srcdir or $builddir?
They should go in $builddir. Having a read-only $srcdir while
building should be possible.
The automake rules for lex et al want to put the sources in
$builddir, but it seems that 'make dist' expects them
Lars Hecking [EMAIL PROTECTED] writes:
Assar Westerlund writes:
a) always remove the directories
b) just remove the directories that were created during `make install'
c) remove the last level of directory if it's empty
d) remove all the levels that are empty
A package system like
Currently automake does not remove directories in `make uninstall' and
I did not find any text regarding this in the GNU coding guidelines
either. So what's the right thing to do here?
a) always remove the directories
b) just remove the directories that were created during `make install'
c)
"Gabor Z. Papp" [EMAIL PROTECTED] writes:
Just trying install gimp from cvs. Installed latest automake
cvs before. Export ACLOCAL_AMFLAGS, and gimp's autogen.sh
complains about m4 files, and suggest using ACLOCAL_FLAGS. I
unset _AMFLAGS, and set _FLAGS, and it seems, that works.
I think that
"Gabor Z. Papp" [EMAIL PROTECTED] writes:
can I use/define somehow additional aclocal directory, where
I can put additional m4 files?
Yes, use `aclocal -I dir' where dir is the directory of your
additional files. If you want that to get included in your
Makefile.in, you can do something like:
23 matches
Mail list logo
