Hi,
When I set a variable with:
m4_define([dc_version_suffix],[devel])
or leave it empty:
m4_define([dc_version_suffix],[])
And then try to conditionally call AC_DEFINE based on whether the
dc_version_suffix is set or not, this doesn't work:
AS_IF([test x$dc_version_suffix = xdevel], [
On 22-12-12 16:18, Eric Blake wrote:
[adding autoconf, as this question technically is independent of automake]
On 12/22/2012 07:52 AM, Jef Driesen wrote:
Hi,
When I set a variable with:
m4_define([dc_version_suffix],[devel])
or leave it empty:
m4_define([dc_version_suffix
On 13/03/11 09:33, Vincent Torri wrote:
On Sun, Mar 13, 2011 at 8:57 AM, Jef Driesenjefdrie...@hotmail.com wrote:
On 10/03/11 11:38, Vincent Torri wrote:
You also have to support static linking.
Does pkg-config support static linking? When I tried to build my own
project, which checks
mi...@gnu.org wrote:
Jef Driesen writes:
Isn't it easier to just check for the presence of the header file and/or
the library file, avoiding pkg-config entirely?
Well, I'd prefer not to guess when possible, and not using pkg-config
for a package that wants you to use it means you end up
On 05/03/11 23:16, Vincent Torri wrote:
On Sat, Mar 5, 2011 at 9:06 AM, Jef Driesenjefdrie...@hotmail.com wrote:
I'm trying to use the PKG_CHECK_MODULES macro to check for an external
library:
PKG_CHECK_MODULES([LIBUSB], [libusb-1.0], [have_libusb=yes],
[have_libusb=no])
This works great,
On 06/03/11 14:23, Vincent Torri wrote:
On Sun, Mar 6, 2011 at 2:08 PM, Jef Driesenjefdrie...@hotmail.com wrote:
On 05/03/11 23:16, Vincent Torri wrote:
On Sat, Mar 5, 2011 at 9:06 AM, Jef Driesenjefdrie...@hotmail.com
wrote:
I'm trying to use the PKG_CHECK_MODULES macro to check for an
Hi,
I'm trying to use the PKG_CHECK_MODULES macro to check for an external library:
PKG_CHECK_MODULES([LIBUSB], [libusb-1.0], [have_libusb=yes], [have_libusb=no])
This works great, except when trying to compile on a system without pkg-config
installed. The configure script fails with a syntax
On 05/01/11 07:38, Ralf Wildenhues wrote:
Hello Jef,
* Jef Driesen wrote on Tue, Jan 04, 2011 at 09:54:15PM CET:
In a project of mine, I generate a header file which contains the
GIT commit sha1. It's generated using these rules:
This works very well, but I also have a windows resource file
Hi,
In a project of mine, I generate a header file which contains the GIT commit
sha1. It's generated using these rules:
FORCE:
$(top_srcdir)/revision: FORCE
@if (test -d $(top_srcdir)/.git cd $(top_srcdir) \
git rev-parse --verify HEAD) revision-t 2/dev/null \
Hi,
I have a couple of questions about running tests. I already know how to
build and run a typical unit tests, with
check_PROGRAMS = ...
TESTS = ...
But in my case the situation is a little different. I'll start with a
little description of the problem I want to solve. I'm writing a
On 12/04/2010 15:58, Peter Johansson wrote:
Jef Driesen wrote:
On 12/04/10 14:59, Peter Johansson wrote:
Also, I would try avoid distributing
`version.h', but not sure how to do that from top of my head.
Why would you not distribute it?
Well, it's a matter of taste, but I see no real
On 13/04/10 11:33, Steffen Dettmer wrote:
I think including the generated source in the tarball is wrong
and can break things. First thing that will break is that you
will have one version.h in srcdir (from the tarball) and
optionally a second one in builddir (from config.status/make).
(config.h
On 02/04/10 14:37, Peter Johansson wrote:
On 4/2/10 7:04 AM, Jef Driesen wrote:
The problem I'm trying to solve is that I already have a version.h
that is generated from a version.h.in template that contains:
#define MYLIB_VERSION_MAJOR @MYLIB_VERSION_MAJOR@
#define MYLIB_VERSION_MINOR
On 12/04/10 14:39, Jef Driesen wrote:
On 02/04/10 14:37, Peter Johansson wrote:
On 4/2/10 7:04 AM, Jef Driesen wrote:
I also have a corresponding version.c file that has the same info, but
for use at runtime:
#include version.h
const int mylib_version_major = MYLIB_VERSION_MAJOR;
const int
On 12/04/10 14:59, Peter Johansson wrote:
Jef Driesen wrote:
mylib_la_SOURCES += version.c
mylib_HEADERS += version.h
BUILT_SOURCES = version.h
EXTRA_DIST += $(srcdir)/version
CLEANFILES += version-t
Took me a while to figure out the escaping of the @ symbol. It seems
to work fine, except
On 02/04/10 11:58, Ralf Wildenhues wrote:
* Jef Driesen wrote on Fri, Apr 02, 2010 at 11:45:20AM CEST:
On 01/04/10 20:31, Ralf Wildenhues wrote:
* Jef Driesen wrote on Thu, Apr 01, 2010 at 02:34:29PM CEST:
Since the .git-version file is a generated file, I would think it
belongs in the build
On 31/03/10 22:45, Ralf Wildenhues wrote:
* Jef Driesen wrote on Wed, Mar 31, 2010 at 02:49:48PM CEST:
Sure. I use both git and subversion, and this are the commands I
would use to retrieve the revision info:
git rev-parse --quiet --verify HEAD
svnversion
The svnversion command is a little
On 16/03/2010 14:22, Peter Johansson wrote:
On 3/16/10 8:29 AM, Jef Driesen wrote:
On 15/03/2010 22:18, Ralf Wildenhues wrote:
* Jef Driesen wrote on Sat, Mar 13, 2010 at 11:21:45PM CET:
I suppose you are referring to solutions like this:
m4_define([mylib_version_revision],m4_esyscmd
On 15/03/2010 22:18, Ralf Wildenhues wrote:
* Jef Driesen wrote on Sat, Mar 13, 2010 at 11:21:45PM CET:
For instance, I prefer to have:
typedef foobar ticks_t;
instead of:
#define ticks_t foobar
It might be possible to achieve the same with AC_CONFIG_HEADERS, but
I don't know how. I had
On 13/03/10 11:34, Ralf Wildenhues wrote:
* Jef Driesen wrote on Mon, Mar 08, 2010 at 02:10:04PM CET:
On 02/03/10 22:17, Ralf Wildenhues wrote:
Hmm, put
AC_CONFIG_HEADERS([config.h foo-api.h])
...
AC_DEFINE([ticks_t], [...], [...])
in configure.ac, create foo-api.h.in with contents
On 02/03/10 22:17, Ralf Wildenhues wrote:
* Jef Driesen wrote on Tue, Mar 02, 2010 at 10:03:35PM CET:
On 01/03/10 19:35, Ralf Wildenhues wrote:
* Jef Driesen wrote on Mon, Mar 01, 2010 at 01:33:46PM CET:
Since a config.h header files is not supposed to be public, that's
not an option. But how
On 01/03/10 19:35, Ralf Wildenhues wrote:
Hello Jef,
* Jef Driesen wrote on Mon, Mar 01, 2010 at 01:33:46PM CET:
How do I get information generated by autotools into my public
header files? For instance I want to define version numbers
somewhere in my configure.ac file, and have the same
Hi,
How do I get information generated by autotools into my public header
files? For instance I want to define version numbers somewhere in my
configure.ac file, and have the same numbers appear in a public header
file without having to modify both files manually? Another example is
that my
Ralf Wildenhues wrote:
* Jef Driesen wrote on Wed, Oct 08, 2008 at 10:24:46AM CEST:
I am shipping the symbols file. In my Makefile.am, I have
EXTRA_DIST = mylib.symbol
to make sure the file is included in the tarball.
But with this approach, msvc users will need to (manually) generate
Ralf Wildenhues wrote:
* Jef Driesen wrote on Thu, Oct 02, 2008 at 05:08:55PM CEST:
mylib.exp: mylib.symbols
if XYZ
$(CPP) -P -DMYLIB_XYZ_SUPPORT - mylib.symbols | sed -e '/^$$/d' $@
else
$(CPP) -P - mylib.symbols | sed -e '/^$$/d' $@
endif
CLEANFILES = mylib.exp
EXTRA_DIST
Ralf Wildenhues wrote:
Hello Jef,
* Jef Driesen wrote on Tue, Sep 23, 2008 at 08:44:47PM CEST:
Brian Dessent wrote:
There are two aspects to the symbol visibility stuff:
[ snip nice explanation ]
Now that I start to understand all the differences, I only need to find
a way how
Brian Dessent wrote:
Jef Driesen wrote:
The MSDN documentation [1] about this issue, gives me the impression
that applications have to relink when new symbols are added to the
library (when not using a DEF). And that's something I would like to
avoid. Actually this statement surprises me, so
I have a cross platform (win32/unix) project that consist of a C library
and a few example applications using that library. The entire project is
build with autotools. With the instructions from the online autotools
book [1], I managed to build both a Windows DLL and a Unix shared
library. But
Brian Dessent wrote:
Jef Driesen wrote:
What are the (dis)advantages of each method? I see differences in usage
(see below), but are there technical differences as well?
It sounds like you already are aware of all the tradeoffs. I don't
think there's a technical difference in the end, i.e
I'm creating my first autoconf/automake project and need some advice on
the standard way to structure my project source code (if there is such a
thing). My project consist of a (libtool) library and a few example
applications that are using the library.
Right now my directory structure is as
Warren Young wrote:
Jef Driesen wrote:
I noticed it is common practice to install the public headers to
$includedir/libfoo
I don't think I've ever seen a 'lib' prefix on a header file directory.
$includedir/foo is far more common.
It's also common for 'foo' to be a diminutive, lowercased
Ralf Wildenhues wrote:
* Jef Driesen wrote on Tue, Jun 03, 2008 at 12:31:29PM CEST:
CFLAGS=-I${includedir}
#include libfoo/header.h
or
CFLAGS=-I${includedir}/libfoo
#include header.h
[...]
It's purely a matter of preference. You're right to segregate the
headers, but a project shouldn't
Warren Young wrote:
Jef Driesen wrote:
I don't really want to mandate a specific style to the users of my
library.
[snip]
Suppose that in one of my public headers, I include one of the other
header files, with libfoo/headerx.h style.
If your headers use the libfoo/header.h style, your
33 matches
Mail list logo
