Hi,
A program I'm currently writing has some binary plugins. What is the
correct way to declare these?
My current approach looks like this:
dbdriverdir = @libdir@/@PACKAGE@/db
dbdriver_LTLIBRARIES = mysql.la
mysql_la_SOURCES = mysql.c
mysql_la_LDFLAGS = -export-dynamic -avoid-version
This
Hi,
probably this is a FAQ, but i couldn't find an answer: How can I tell
automake to check for a C++ library (i.e. that contains no C symbols)?
Simon
--
PGP public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: 10 62 F6 F5 C0 5D 9E D8 47 05 1B 8A 22 E5 4E
On Sun, 27 Aug 2000, W. Reilly Cooley, Esq. wrote:
Now, maybe I'm misunderstanding Make's macro-passing, but in order for
the DESTDIR passed to the make in the first place, doesn't the @$(MAKE)
line need something like 'DESTDIR=$(DESTDIR)' ? Would this be the
correct way to fix this?
No,
Hi,
One of my packages comes with a shared library and a program that should
link against it. How can I tell automake to link against a not-yet-built
library and set a proper -rpath in the executables (i.e. one that points
to @libdir@)?
Simon
--
PGP public key available from
On Thu, 5 Oct 2000, kitkat wrote:
Hi Simon, thanks for your quick reply !
This one took a little longer however... :-)
1.) xxx.h (gets changed)
2.) xxx.cxx ( xxx.h is included by xxx.cxx - this dependency forces
recompilation of xxx.cxx)
3.) now not only the c-compiler should run but
On Thu, 26 Oct 2000, Robert Boehne wrote:
[Finding libraries from other packages]
What is the "best" way to coerce Automake into installing
config.h in $(prefix) ?
Not at all. Instead, create m4 macros that search for the libraries
somehow and place them in ${datadir}/aclocal. A common
On Mon, 30 Oct 2000, Bob Friesenhahn wrote:
If we should not be installing config.h files, then it would be
beneficial for Automake (or Autoconf) to support an automated way to
provide the benefits of config.h, but in a better form.
How about the bin/package-config approach: configure
On Thu, 16 Nov 2000, Tim Heath wrote:
-D_POSIX1C_SOURCE -D_HPUX_SOURCE -D_REENTRANT
Is there a way to automate this with an AM or something?
There is, in fact, but these definitions are better placed as "#define"s
at the beginning of source files. This way, you can easily tell from the
On Fri, 17 Nov 2000, Tim Heath wrote:
I don't know of a way to use a #define within a source file for a
compiler flag. Can you tell me the other way to accomplish this goal?
-D is the compiler flag for "add this definition as if it were
#defined". Thus, the source should begin with
#define
On Fri, 17 Nov 2000, Tim Heath wrote:
How do I add compiler flags? What AM is necessary to accomplish that?
Make your configure.in add them to $CFLAGS, before AC_PROG_CC (to make
sure the compiler actually accepts them).
Simon
--
GPG public key available from
On Mon, 20 Nov 2000, Tim Heath wrote:
AM_CXXFLAGS = -D_POSIX1C_SOURCE -D_HPUX_SOURCE -D_REENTRANT
[...]
If you know of a better way please feel free to share it with me. I am
interested in how to do and if/then to use this only if I am compiling
on HPUX 11.0 with aCC etc.
Why only with
Hi,
for a project of mine I need support for java .class files, and as I'd
like to do this the right way I've thought I might as well try to hack
automake's Java support.
What do you think about something like this:
- Makefile.am -
data_JARS = foo.jar
foo_jar_JAVA = Foo.java
data_JAVA
Eric,
On Fri, Jan 31, 2003 at 11:19:29PM -0500, Eric Siegerman wrote:
foo_jar_JAVA = Foo.java
Don't forget that JARs can contain other things than .class
files; it'd be nice if there was an automakish way to say
include these other files too.
Hrm, what if an archive would be treated like
Aidan,
Automake does not seem to differenciate between flex generated c++ files and c
files
Not if it has to guess. Use .ll or .l++ as the extension for your lex
file, drop the -+ and watch it work. :-)
Reason behind that: automake needs to know at Makefile.in generation
time which compilers
Alexandre,
On Tue, Feb 04, 2003 at 08:00:07PM +0100, Alexandre Duret-Lutz wrote:
Simon == Simon Richter [EMAIL PROTECTED] writes:
[Archives as directories]
Simon ... Hrm, that would go in the direction of generic archive target
Simon support, and one would have to think about files
Jean-Guillaume,
So, in the Makefile.am of the src dir, I put something like:
INCLUDES = $(PROJECT_ROOT_DIR)/include -I$(XERCES_DIR)/include
I presume you're not pasting... There's a -I missing here. How about
INCLUDES = -I${top_srcdir}/include ${XERCESINCDIR} ...
top_srcdir is
Hi,
now that the difficult part of my exams is over, I can start to think
about hacking Java support in automake.
Currently, when compiling Java files to bytecode, this happens with
javac (hardcoded, but can be overridden with an argument to make). The
class files are output to the build root
David,
I'm trying to configure a program such that it will build properly,
whether or not the building is done from the top of the source tree,
or in a separate build directory. If a separate build directory is
used, it is necessary to copy one directory from $top_srcdir/examples
to
David,
This will make things easier for programs that need to know what files are
being installed, so they can keep a list of installed packages, that can
be updated, deleted, etc...
The canonical way to do this is to install into a separate dir and
create symlinks (e.g. using the GNU stow
Dan,
configure: error: Autoconf 2.54 or better is required.
Is it installed? Is it in your PATH? (try running `autoconf
--version')
Is it working? See also config.log for error messages before this
one.
Have you looked at the config.log? Most likely, autoconf itself is
there, but
Scott,
For this project I have some code that I want to share between two
separate software projects. I would like each of these software projects
to conditionally-compile and link my software extensions.
AC_ARG_ENABLE([extra],dnl
[ --enable-extra Enable extra hooks],[
ln -s
Hi,
Should I include aclocal.m4 in MAINTAINERCLEANFILES, and regenerate it
every time i regenerate the built files? (runs autogen.sh)
Usually I don't care about that file. It will be regenerated every time
someone calls aclocal, so there is no need to clean it out.
Is it advisable to keep
Hi,
I need to have automake (1.7.6) create a Makefile.in in a directory that
changes often. Therefore I introduced an environment var WORDIR like so:
CONFIG_FILES( [ path/${WORKDIR} ] ). Of course this fails as automake tries
to create path/${WORKDIR}/Makefile.in, not expanding the shell var
Marc,
I want to import a Makefile.mk file which has variables generated by an
autoconf/automake project which i depend on. This toolkit has most of
the autoconf tests i need already run.
You have two options:
- Have the depended-on package supply a shell script that prints
Hi,
[Info files being built in source dir]
FWIW, having a read only source directory is our goal.
When the source dir is readonly, noone can change the texinfo files. If
noone can change the texinfo files, there is no need to rebuild the info
files, so it doesn't matter that they're in a
Simon,
[Info files being built in source dir]
When the source dir is readonly, noone can change the texinfo files. If
noone can change the texinfo files, there is no need to rebuild the info
files, so it doesn't matter that they're in a readonly directory.
I don't think this is true in
Hi,
Simply using the .SILENT: ... pseudo-target goes a little too
far, I would prefer something similar to the behaviour of the
Linux kernel Makefiles, e.g., printing only the line
Compiling foo.c
when foo.c is compiled.
Is there a portable way of doing this?
Modifying the rules that
Hi,
AC_MSG_CHECKING([whether dependency tracking should be enabled])
if test -d $srcdir/CVS ; then
AC_MSG_RESULT(it should)
AM_INIT_AUTOMAKE
else
AC_MSG_RESULT(it should not)
AM_INIT_AUTOMAKE([no-dependencies])
fi
You probably want AM_MAINTAINER_MODE.
Hi,
Harald Dunkel wrote:
I would like to create the directories for some
$SUBDIRS as needed at runtime, e.g.
erm, why?
Unfortunately Automake complains about the missing
directories in the source tree.
Yes, because the structure of the source tree is supposed to be pretty
much static
Hi Stepan,
Stepan Kasal schrieb:
AC_SUBST([FOO], [foo
bar])
[...]
Automake could generate lines like this:
FOO = @FOO@@\n@
There are a lot of cases, in fact, the majority, where the substituted
string is only known at configure time, when the Makefile.in files have
long been generated.
Hi,
BRM wrote:
AC_CONFIG_FILES([Makefile os/Makefile
os/${target_os}/Makefile arch/Makefile
arch/${target_cpu}/Makefile])
Indeed, that will not work. These are configure time substitutions,
however automake runs way before that, and there is no way it could know
all the possible values.
Hello,
BRM schrieb:
Version 1: http://tinyurl.com/bhp9v
I've based my changes upon that one. These are in (messed up due to line
breaks) patch format, with comments in the middle.
| --- hello_world_3.orig/arch/Makefile.am 2005-12-20 01:57:23.0
+0100
| +++
Hi,
Jason Kraftcheck wrote:
Automake includes the contents of the $LIBS variable in all link commands,
including linking libraries. This results in the following behavior:
3) If libtool is creating a shared library, and one or more of the libraries in
$LIBS is static, behavior is
Hi,
Geoffrey Hutchison schrieb:
OK, my automake-driven project has managed to find a C++ compiler bug
due to optimization. Fortunately, the problem is only in a few files in
a subdir.
Erm, does it affect all C++ compilers, or just specific ones?
I suppose it is the latter only, so I'd
Hi,
Thomas Porschberg schrieb:
do Makefiles created from automake benefit from dualcore CPUs
and is the build process speeded up ?
Most Makefiles generated from automake are SMP safe and benefit from
multiple processors if make's -j option is used. They usually also
benefit from -j2 on
Hi,
Vladimir Vassilev schrieb:
If there are projects which address the same issue, please send some
pointers.
There are a few projects that do this; however none of them uses
automake to build the makefiles for the kernel objects; rather, they
have a Makefile.in that is not autogenerated,
Hi,
Benoit Perrot wrote:
As `automake' (ie automake-1.7) is searched, autoconf fails.
Just call it explicitly once, the resulting Makefile.in will contain the
proper name for eventual updates then; i.e.
aclocal-1.9
autoheader
automake-1.9
autoconf
At least that works for me. :-)
Simon
Hi,
On Fri, May 14, 2010 at 03:53:29PM -0700, Natalie Tasman wrote:
I have one target which is actually a utility used during *build* time. Is
it possible to specify one target which should *not* be built with the
cross-compiler, but natively instead?
Not directly. The trick is to have a
Hi,
On Mon, May 17, 2010 at 03:37:37PM -0700, Natalie Tasman wrote:
I've created a separate configure.ac and Makefile.in for the native
project. However, when invoking configuration from the top-level
(cross-compiled) project, AC_CONFIG_SUBDIRS passes various options,
including directives
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I have a library that, among other things, has a number of functions
related to event handling with timeouts. In order to get reliable
results, I have to use long timeouts, which add up in the total test
time. Is there a way to have tests run in
Hi,
On 04.05.2013 17:00, Andrey Borzenkov wrote:
But still - what are rules to decide which files are included in make
dist if conditionals are used?
All of them.
Simon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I have a project where I let flex generate a header file -- however
ylwrap throws this file away. According to bugs #8844 and #9933 this
should work now -- is that a regression, or have the bugs been closed
before the updated code made it into a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 11.06.2013 20:16, Stefano Lattarini wrote:
Sorry for the dumb question, but: which version of Automake are
you using? And: are you sure the ylwrap script are you using is
actually in sync with that version?
Sorry for being unclear --
Hi Václav,
- src/Makefile.am: Listing headers for dependencies and source files.
(http://bazaar.launchpad.net/~log4cplus/log4cplus/trunk/view/head:/src/Makefile.am)
You do not need to list the headers as source files as long as they are
listed somewhere.
The dependencies start out empty
Hi,
On 01.08.2013 00:46, Peng Yu wrote:
I'm not able to understand the usage of TESTS in Makefile.am, as there
are many other things discussed in conjunction with TESTS and which
obscures the description of TESTS. Could anybody point me a minimal
example (without any things unrelated to
Hi,
On 11.11.2014 18:50, fr33domlover wrote:
When I ran `make distcheck`, it failed because the HTML files don't get
cleaned
by `make distclean`. That makes sense, but specifically for my package this is
not an error.
If you assume that few people build these files, they should be
Hi,
On 11.11.2014 21:07, fr33domlover wrote:
When the files are distributed, the distcheck should recognize that
these belong in the source package, and not show an error.
Hmmm I think I didn't make myself clear. So just to make sure, before I cause
confusion: The files are indeed
Hi,
On 11.11.2014 22:02, fr33domlover wrote:
If they are distributed, the distcheck target should not complain,
because it should expect the files to be there.
The files are not specified in any variable with 'dist_' prefix. They are
distributed because I wrote a dist-hook. Normally I would
Hi Jamil,
On 14.03.2015 17:10, Jamil Egdemir wrote:
# make install
Assume that most users only have the files installed that make install
copied. Thus, you need to install the bitmap to an appropriate
directory, e.g. pkgdatadir:
pkgdatadir = $(datadir)/$(PACKAGE)
pkgdata_DATA =
Hi,
On Fri, Jan 20, 2017 at 12:44:53PM -0600, Bob Friesenhahn wrote:
> install-exec-local:
> mkdir -p ${DESTDIR}${bindir}
> ln -s ${DESTDIR}${pkgdatadir}/croco.php ${DESTDIR}${bindir}/croco
With automake, this could also be written as
install-exec-local:
$(MKDIR_P)
Hi,
On 19.10.2017 22:29, Simon Sobisch wrote:
> The autoconf parts are fixed now [1], but there's one thing in the
> Makefiles where we generate a binary with the compiler we've generated
> directly beforehand. This obviously can't work and I'd like to skip
> this and telling people to do so on
Hi,
On Fri, Nov 22, 2019 at 01:27:34PM +0100, Darshit Shah wrote:
> Until here, it's all good. But then, I don't want to mention the
> sources for each of the libraries separately. They are always the
> same, and I would like to avoid having to manually keep them in sync
> when stuff changes.
Hi,
On 29.03.21 16:20, Peng Yu wrote:
> crypt(3) does not need -lcrypt on macOS, but need -lcrypt on Linux.
> How does autotools determine what library is need to be linked based
> on the source code? Thanks.
It compiles a short test program that calls crypt, then tries to link it
without any
53 matches
Mail list logo
