[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 so
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 incl
"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
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 shoul
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
Calvin Arndt <[EMAIL PROTECTED]> writes:
> I use autoconf/make versions 2.52/1.6.1
>
> The configure script created by the build system absolutely and
> completely fails on systems with 2.13/1.4. In addition my
> configure.in fails when used with automake 1.7
This is confusing. The generated
[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
> autoconf/functions.m4:1
[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
> configu
<[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
"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 buil
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 changin
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
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
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 the
Tom Tromey <[EMAIL PROTECTED]> writes:
> Derek> Apparently BSD wants something like the following:
> Derek> .include "file"
> Derek> or
> Derek> .include
>
> Yuck. Does make have -I options too?
Yes. From make(1):
-I directory
Specify a directory in which to search
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
>
>
>
> --- /usr/
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
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 c
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 coer
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 Bals
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 t
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 al
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) remo
"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
Akim Demaille <[EMAIL PROTECTED]> writes:
> ACLOCAL_AMFLAGS = -I dir
>
> which is slighly better, since I don't think autoreconf will recognize
> the former, while it definitely knows the latter.
Yes, but autoreconf 2.13 does not understand that. :-(
/assar
"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 li
26 matches
Mail list logo
