en parametes exposed...
___
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
___
...ich hab' noch einen Koffer in Berlin...
Akim Demaille wrote:
> OK, I'll submit another scenario to you.
[...]
oh yes, I know that story. It happens again and again.
And I agree that at some point you need a rupture to rewrite
the tool on a more robust ground. I have no problems with the
fact that you did break backward compatibilit
hi there,
I'v run into another problem with autoconf 2.52:
at some point, I set the language to be used to C++,
as I code in C++ and want all tests to be performed
with C++.
However, the language is automagically set back to C
before the actual tests are performed, such that some
tests fail. I
I'm using autoconf with a greenhills cross-compiler.
It compiles source code into .ppc executables, but
generates auxiliary files with other extensions on-the-fly
(.map, for example).
Unfortunately, the way autoconf detects a compiler's
default executable extension is by making some guesses,
and
Ralf Wildenhues wrote:
Does the patch below fix it?
It looks good, though there is at least one more extension: '.inf',
which is generated with optimization. Other files with extensions
'.dbo', '.dla', etc. are created when object files are produces,
but these don't seem to confuse configure.
Ralf Wildenhues wrote:
Hi Stefan,
* Stefan Seefeld wrote on Fri, Nov 11, 2005 at 06:08:29PM CET:
Ralf Wildenhues wrote:
Does the patch below fix it?
It looks good, though there is at least one more extension: '.inf',
which is generated with optimization. Other files with extens
I have just read about AC_CONFIG_MACRO_DIR as a means to
specify additional places to look for M4 macros.
I notice that the generated configure script still
contains traces of that macro, notably, a check for
the directory that was given as argument.
What is the purpose of this ? Since macro look
I have just read about AC_CONFIG_MACRO_DIR as a means to
specify additional places to look for M4 macros.
I notice that the generated configure script still
contains traces of that macro, notably, a check for
the directory that was given as argument.
What is the purpose of this ? Since macro look
Ralf Wildenhues wrote:
> Hello Stefan,
>
> * Stefan Seefeld wrote on Tue, Sep 12, 2006 at 04:50:40PM CEST:
>> I have just read about AC_CONFIG_MACRO_DIR as a means to
>> specify additional places to look for M4 macros.
>>
>> I notice that the generated configure s
Ralf Wildenhues wrote:
> I guess Autoconf needs to either update the documentation to mention
> that AC_CONFIG_MACRO_DIR is not supposed for packages that do not
> intend to ship macro files, or remove the test for the existence of
> the directory. Not sure as to which fits better, as I'm not sur
Keith MARSHALL wrote:
> Stefan Seefeld wrote, quoting Ralf Wildenhues:
>>> The idea is that your final package tarball should contain what's
>>> needed to recreate the generated configure script.
>> It is one thing for a source package to contain M4 code, but ano
I'm trying to use AC_PROG_LEX to discover whether flex (or lex) is
available. During testing I found out that, even when neither is
available, the LEX variable is set to ':' instead of being empty.
And sure enough, I subsequently found this in the programs.m4 code:
AC_DEFUN_ONCE([AC_PROG_LEX],
hi there,
I'm in the process of changing a set of
configure.ac files to make them compatible
with autoconf 2.52. Looking through the
generated configure files I see a set of
output variables all related to the new
AC_INIT macro:
PACKAGE_NAME
PACKAGE_TARNAME
PACKAGE_VERSION
PACKAGE_STRING
PACKAGE
hi there,
I just upgraded from autoconf 2.52 to autoconf 2.53,
and I get quite a number of warnings due to the fact
that I'm still using acconfig.h. I'm being suggested
to use the third argument of AC_DEFINE instead to
provide a template for the config.h.in file I want.
Reading up on the autoconf
Paul Eggert wrote:
>>AH_TOP ([
>>
>
> Your problem is caused by that space after "AH_TOP".
a space ! That's rediculous !
Reminds me why I don't like macro languages. Oh well...
Thanks for your help !
Stefan
hi there,
I'v got another question / bug report:
I'm using the AC_INIT() macro with three
arguments, which (even though it is not documented,
as I wrote in an earlier post) generates a set of
variables PACKAGE_SOMETHING that get automatically
inserted into my config header.
That's a big problem,
hi there,
here is yet another problem:
my configure.ac file contains a line like
AC_CONFIG_FILES([bin/Prague-config:config/Prague-config.in],
[chmod +x bin/Prague-config])
meaning that I want to generate a file $top_builddir/bin/Prague-config
from $top_srcdir/config/Prague-con
and finally...
In a little test I use three versions of AC_DEFINE_UNQUOTED:
AC_DEFINE_UNQUOTED($ac_tr_decl, 1, [yadayada])
AC_DEFINE_UNQUOTED(foobar1, 1, [yadayada])
AC_DEFINE_UNQUOTED(foobar2, $ac_tr_decl, [yadayada])
in the first case the variable name itself is a variable,
in the s
Akim Demaille wrote:
> | In a little test I use three versions of AC_DEFINE_UNQUOTED:
> |
> |AC_DEFINE_UNQUOTED($ac_tr_decl, 1, [yadayada])
>
> This is midly discouraged in the doc.
not in the docs I read. Please show me where it is discouraged in:
http://www.gnu.org/manual/autoconf/html_m
hi there,
I'd like to use AC_CONFIG_SUBDIRS to configure
a set of sub-packages, but I'm missing some functionality:
I'd like to control what to do if configuration fails.
Some sub-packages are mandatory, so if AC_CONFIG_SUBDIRS
fails, the parent configure should report an error and bail out.
Some
Earnie Boyd wrote:
Jeff Squyres wrote:
On Mon, 28 Oct 2002, Stefan Seefeld wrote:
I'd like to use AC_CONFIG_SUBDIRS to configure a set of sub-packages,
but I'm missing some functionality:
I'd like to control what to do if configuration fails. Some sub-packages
are m
hi Akim,
here is an example of what usage I have in mind:
I'd like to make a distribution for the 'Fresco'
project. The code is a set of libraries, plugins,
demos, etc., which are - for convenience - all
to be configured / build with a single 'configure'.
Among the components are some that are m
yes,
AC_CONFIG_SUBDIRS(dirs, [action-if-succeeds], [action-if-fails])
is exactly what I had in mind. The parent configure should however
really test the script's exit status and not rely on the creation
of a file. Which file should be choosen ? configure could still
fail after any one file has be
hi there,
I'm in the situation where I run the macro
AC_PATH_PROG with a program 'foo-config' and a given path,
and then, if that failes, I call it again (after some other
processing) with a different path.
autoconf will silently skip the second test as it has the result
of the first still in th
Akim Demaille wrote:
If I read you correctly, you are hard coding a change of path in
configure.ac. Don't do that. Set it before running configure, and
things will run properly.
ok, I guess a little bit of explanation is in order (though I figured
for the problem at hand I would just name the
hi there,
I'm writing a m4 test that calls AC_PATH_PROG.
My test takes an argument that is a package name.
This name is not a valid shell variable name, so I have
to calculate a variable name. autoconf generates a variable
'as_tr_sh' which is used for similar purposes, but I'm not
sure it is 'offi
hi there,
some weeks ago we discussed ways to enhance the AC_CONFIG_SUBDIRS
macro, to be able to let subdir configure calls fail in a controlled
way. What happened to that feature request ? Do you plan to make
enhancements in that direction ?
The situation is this: I'm working on the build system
27 matches
Mail list logo
