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
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
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
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 following
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
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:
Also sprach Guillaume Rousse:
+# Objective Caml
+register_language ('name' = 'ocaml',
+ 'Name' = 'Objective Caml',
+ 'config_vars' = ['OCAMLDEP', 'OCAMLC'],
+ 'flags' = ['OCAML_INCLUDES', 'OCAMLFLAGS'],
+ 'compiler' = 'COMPILE
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 compilation modes, native and
bytecode
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
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'. Prehaps
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:
automake
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 detailed in autoconf documentation
http://www.gnu.org
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 -f
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
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' \
...
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 a bit.
* Guillaume Rousse
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 this is supposed to take
place on maintainer's host anyway.
--
Guillaume Rousse
Projet Estime, INRIA
Domaine de
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
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 perl
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
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
installations you will usually have to set more options
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
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_LIBTOOL. However, as a side-effect, configure script
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:
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
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
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
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
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
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,
Guillaume initrd_SCRIPTS
31 matches
Mail list logo
