I'm trying to implement conditional installation of stuff with
non-standard location, such as init-script. The basic idea is not to
install them unless the user specify a location when running ./configure
However, it doesn't work with automake conditional
in configure.ac:
AC_ARG_WITH(
in
Alexandre Duret-Lutz wrote:
"Guillaume" == Guillaume Rousse <[EMAIL PROTECTED]> writes:
[...]
Guillaume> In this situation, I have an installation target for
Guillaume> initrd scripts in generated Makefile, using
Guillaume> $(initrd_SCRIPTS) as dependency. However,
Hello.
A colleague of mine developped a custom language for natural language
processing, called DyALog
(http://atoll.inria.fr/~clerger/work.html#DyALog). In order to ease
module development, he also extended automake to support this language.
However, he is currently maintaining it as a patch a
Ben @ Yahoo wrote:
I am trying to install automake 1.9.4 from source on my system. The system is a
Slackware 10.0.0 installation on a PII/233. I upgraded m4 to 1.4.2, and also
installed Diff Utils 2.8.1 from source.. Additionally, Bison 1.875 is
installed, from source I believe. Otherwise, all so
Maybe a stupid question, but I don't understand how config file location
is to be handled with autotools.
autoconf evaluates quite logically sysconfdir to %(prefix)/etc, meaning
/usr/local/etc by default, and /usr/etc when prefix is set to /usr.
However, in real life, I never saw those director
Hello list.
I'm facing a painful issue with the deprecation of AM_PROG_MKDIR_P,
causing a warning to be issued, because it seems to be indirectly called
by gettext macros, and I don't understand how to fix it...
Here is the exact error message:
[guillaume@beria sympa-cleanup]$ autoreconf
con
Default LDPATH and CPPFLAGS values are empty, making all AC_LIB_CHECK
and AC_HEADER_CHECK unable to detect libraries installed under
/usr/local. Whereas an knowledgeable user will export these variable
before running ./configure, many other will just be unable to build
software properly (and some m
I'm trying to convert a program creating static libraries only to
libtool use. In configure.ac, I just changed AC_PROG_RANLIB to
AC_PROG_LIBTOOL. However, as a side-effect, configure script tries to
use gcc instead of g++, and fails to find correct headers.
The initial configure.ac looks like:
AC_
autoconf does provide two macros that requires external files:
- AC_PROG_INSTALL requires install.sh
- AC_CANONICAL_HOST requires config.{guess,sub}
However, whereas the first one is provided by autoconf itself, the
second ones are provided by automake only (at least on my distribution).
Should t
Ralf Wildenhues wrote:
> Hi Guillaume,
>
> * Guillaume Rousse wrote on Thu, Mar 09, 2006 at 05:09:30PM CET:
>> I'm trying to convert a program creating static libraries only to
>> libtool use. In configure.ac, I just changed AC_PROG_RANLIB to
>> AC_PROG_LI
On a x86_64 host, libdir is expanded to exec_prefix/lib, as on i586.
However, most Linux distribution (and I guess FHS too) specify to use
exec_prefix/lib64, to make simultaneous installation of 32 and 64 bits
programs possible.
Am i supposed to manually set libdir according to build host to get
c
Bob Proulx wrote:
> Ralf Wildenhues wrote:
>> * Guillaume Rousse wrote:
>>> Am i supposed to manually set libdir according to build host to get
>>> compliance with such constraint ?
>> Yes, you can specify --libdir at configure time. Note for system
>> ins
Hello.
I'm investigating the use of autotools for building and installing a
perl program, because standard tools as MakeMaker or Module::Install,
while perfectly suited for perl modules, are quite limited when dealing
with programs with data, configuration, etc...
However, I'm having some trouble
Bob Friesenhahn wrote:
> On Wed, 12 Apr 2006, Tyler MacDonald wrote:
>
>> I'm working on moving a project over to automake/libtool right now.
>> There's perl modules in some subdirectories with their own Makefile.PL's.
>>
>> Is there already some m4 macros around that will let me build per
I tried to have a look at how sed substitutions are handled by
config.status, so as to help this guy, but I get lost in multiple format
transformations...
In particular, the final 't t' at the end of each substitution pattern
is mysterious for me.
--- Begin Message ---
I am trying to install btpar
Ralf Wildenhues wrote:
> Hi Guillaume,
>
> * Guillaume Rousse wrote on Wed, Apr 19, 2006 at 10:46:11AM CEST:
>> I tried to have a look at how sed substitutions are handled by
>> config.status, so as to help this guy, but I get lost in multiple format
>> transformatio
A colleague of mine has some concerns with source distributions.
He is using a private lexical resource to produce C source code, and he
use this source code in its own program. Unfortunatly, he doesn't have
the right to distribute the lexical resources, but assumes he can
distribute the generated
I read the automake and autoconf manual several times, but I'm still a
bit uncertain at how to manage compilation flags properly, meaning:
- which flags to use
- where to use them
First, you have per-primary targets options (discarding non-C language
ones):
foo_CPPFLAGS
foo_CFLAGS
foo_(LIBADD|LDA
Using the following Makefile.am, make distcheck report everything's OK.
However, the main files, rpmbuildupdate.in rand pmbuildupdate.comp.in
are obviously missing, as I forgot to list them in EXTRA_DIST.
Is this a bug, or am I missing something ?
--
Guillaume Rousse
Projet Estime,
Guillaume Rousse wrote:
> Using the following Makefile.am, make distcheck report everything's OK.
>
> However, the main files, rpmbuildupdate.in rand pmbuildupdate.comp.in
> are obviously missing, as I forgot to list them in EXTRA_DIST.
>
> Is this a bug, or am I missi
ty to w32 systems such as MinGW, people there like to
> do
> ./configure --prefix=C:/some/path
>
> (they typically don't mind if DESTDIR support does not work in that
> case).
In that particular case, I'm not sure a rpm-handling software is really
useful elsewhere as Linux, but anyway this is good to know. Thanks for
the tips.
--
Guillaume Rousse
Projet Estime, INRIA
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex - France
sult from make's VPATH search.
>
> Was this understandable?
Yes, thanks for those explanations.
Would not distcheck target be more foolproof then if it used a random
writable temporary directory rather than a local one ? I have no clue
however about the portability of mktemp(1), but th
Ralf Wildenhues wrote:
> Hello Guillaume,
>
> Do you use Automake? If yes, or if you want to add support for ocaml to
> Automake, then probably its list would be more appropriate. If not, all
> of the following has relevance without Automake, it's just colored that
> way
I'm having troubles building a large ocaml library, where code is
divided into subdirectories for maintainance ease, as each of them
relies on optional dependencies.
The final stage (linking) has to be done from the top-level directory,
so as to create a single library. As linking order is strict,
I'm using this rule to substitute values in a sourcefile:
corelib/camlimages.ml: Makefile corelib/camlimages.ml.in
rm -f corelib/camlimages.ml corelib/camlimages.ml.tmp
sed \
-e 's,@PACKAGE_VERSION\@,$(PACKAGE_VERSION),g' \
...
corelib
Ralf Wildenhues wrote:
> Hello Guillaume,
>
> * Guillaume Rousse wrote on Thu, Nov 23, 2006 at 04:46:50PM CET:
>> I'm using this rule to substitute values in a sourcefile:
>> corelib/camlimages.ml: Makefile corelib/camlimages.ml.in
> [...]
>
>> As deta
Guillaume Rousse wrote:
> For 1), the attached patch seems to be enough.
It seems to have been forgotten somewhere, here it is again.
--- /usr/share/automake-1.9/depcomp 2006-09-27 03:44:18.0 +0200
+++ depcomp 2006-11-21 13:57:48.0 +0100
@@ -508,6 +508,10 @@
rm
Ralf Wildenhues wrote:
> Hello,
>
> * Stepan Kasal wrote on Mon, Nov 27, 2006 at 07:56:20PM CET:
>> * Makefile.in <-- .depend
>> This is because automake creates Makefile.in from Makefile.am and all
>> included files. Your Makefile.am includes .depend.
>
> To rephrase this more to the point:
> a
Stepan Kasal wrote:
You specified the dependency:
corelib/camlimages.ml <-- Makefile
This is not correct. You should specify the ultimate primary sources
instead of `Makefile'. Prehaps `Makefile.am' is enough?
It was to catch configure runs, so I used config.status instead.
I hope this
Stepan Kasal wrote:
Hello,
On Thu, Nov 30, 2006 at 09:31:19AM +0100, Guillaume Rousse wrote:
Stepan Kasal wrote:
You specified the dependency:
corelib/camlimages.ml <-- Makefile
This is not correct. You should specify the ultimate primary sources
instead of `Makefile'.
Here is my first attempt at providing ocaml support in automake.
My current point is just to allow automatic dependencies computation at
configure stage, but it seems to be quite linked with
compilation-related values in language registration template.
Here are the current issues:
Ocaml actually
Also sprach Ralf Wildenhues:
> Hello Guillaume,
>
> Thanks for your work on this, and apologies for my lack of feedback.
>
> * Guillaume Rousse wrote on Fri, Dec 15, 2006 at 06:23:36PM CET:
>> Here are the current issues:
>> Ocaml actually support two different com
Also sprach Guillaume Rousse:
>>> +# Objective Caml
>>> +register_language ('name' => 'ocaml',
>>> + 'Name' => 'Objective Caml',
>>> + 'config_vars&
Hello.
My source tree is something as
foo1.ml
foo2.ml
subdir/foo3.ml
subdir/foo4.ml
etc...
My current option is to build object files in the same directory as the
corresponding ource file (actually, it is ocaml compiler defaut
behaviour). It makes computing object files list quite easy:
MYSOURCEF
Also sprach Ralf Wildenhues:
> This machinery is all present in automake.in (but not accessible from
> outside). Sorry, I haven't worked on this more yet.
Which basically there is no other solution without modyfing automake
currently, right ?
OK, I'll release camlimages in current state (after al
Hello.
I just found an issue in GNU make handling of empty variable in
substitutions:
A = foo
LIST = $(A) $(B)
LIST_H = $(LIST:=.h)
all:
echo $(LIST_H)
With GNU make 3.80, LIST_H is incorectly expanded to "foo.h .h", whereas
in make 3.81, this is correctly expanded to "foo.h" only. How t
Ralf Wildenhues wrote:
> I think POSIX requires the part between `:' and `=' to be nonempty, but
> not the part after `='. So write
>
> A = foo.h
> LIST = $(A) $(B)
> LIST_H = $(LIST:.h=)
>
> Hope that helps.
It works, thanks.
Still on the portability issue, I have some doubts about the followi
Guillaume Rousse wrote:
> Also sprach Ralf Wildenhues:
>> This machinery is all present in automake.in (but not accessible from
>> outside). Sorry, I haven't worked on this more yet.
> Which basically there is no other solution without modyfing automake
> currently, rig
Hello list.
I'm trying to sanitize sympa (www.sympa.org) usage of autotools. I made
a few attempts to use automake builtin gettext support, as explained at
http://www.lrde.epita.fr/~adl/autotools.html, but I don't think that is
really suited for my needs.
First, sympa is mainly a perl progra
Hello list.
I'm trying to use automake builtin support for a perl project (sympa).
According to the gettext manual, I only need AM_PO_SUBDIRS macro, not
AM_GNU_GETTEXT_VERSION, as I only need PO files handling, and not native
code linking support. However, this is not enough to have autoreconf
40 matches
Mail list logo
