Re: AC_DEFUN Syntax

Hello Husam, * Husam Senussi wrote on Sun, Sep 06, 2009 at 11:00:58AM CEST: > I had problem building make files for existing project because > autconf was falling, we had look around I found > the autoconf was falling because macro definition which looks like this > > AC_DEFUN([NAME], > [ >

Re: Compiler characteristics

* NightStrike wrote on Sun, Sep 06, 2009 at 12:08:23PM CEST: > How do you test to see if the compiler supports a given option? You could temporarily add it to CFLAGS and either do a compile or link test, to find out. That won't catch (non-GCC) compilers though that only produce a warning upon unk

Re: AC_DEFUN Syntax

Hello Husam, * Husam Senussi wrote on Sun, Sep 06, 2009 at 07:57:17PM CEST: > >Yes. The latter is the public API. The third argument is currently > >used by some code, but is not part of the public API, so you should > >not use it. > > OK will change them because with third argument result on

Re: AC_DEFUN Syntax

* Husam Senussi wrote on Mon, Sep 07, 2009 at 10:25:41PM CEST: > >That probably doesn't help you much, but I don't know what better help > >to give you, given this information. Maybe if you have problems, you > >could post some code. > > Will this the macro which causing the autocnf errors and i

Re: caching variables

Hello Sam, * Sam Steingold wrote on Wed, Sep 02, 2009 at 05:26:46PM CEST: > I want to cache several dependent variables, and I cannot figure out > how to do that correctly. * Sam Steingold wrote on Wed, Sep 02, 2009 at 07:51:20PM CEST: > does the cache variable name matter? > e.g., ac_cv_have_rea

Re: order of programs run by autoreconf

Hello Vincent, * Vincent Torri wrote on Tue, Sep 08, 2009 at 09:59:03AM CEST: > > In the autoconf manual, it is said that autoreconf runs the programs > autoconf, autoheader, aclocal, automake, libtoolize, and autopoint. > But when I run autoreconf -v to see what is running, the order is > differ

Re: Adding an external project to autoconf

Hello Dan, * Dan Smithers wrote on Wed, Sep 09, 2009 at 11:33:54AM CEST: > > AC_CONFIG_SUBDIRS (zlib compression boost_ext) Please remove the space before the '('. See 'info Autoconf "Autoconf Language"' for why. And yes, it is perfectly possible to have subpackages that do not use Automake, o

Re: Confusing sample in autoconf manual

Hello santilín, NightStrike, * NightStrike wrote on Wed, Sep 02, 2009 at 05:44:16PM CEST: > On Sun, Aug 9, 2009 at 1:08 PM, santilistas wrote: > > By the way, is this the correct list to send this remarks? Yes; although bugs in Autoconf can go to the bug-autoconf list. Sorry for the long delay.

Re: Autoconf and DJGPP

* Rugxulo wrote on Wed, Sep 09, 2009 at 09:44:15PM CEST: > > I don't think that's necessary at this point. *NEW!* Andris Pavenis > seems to have fixed the bug (at least with 2.05b) via a small patch > (see below): > > http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2009/09/0

Re: caching variables

* Sam Steingold wrote on Fri, Sep 11, 2009 at 06:15:32PM CEST: > On Mon, Sep 7, 2009 at 4:59 PM, Ralf Wildenhues wrote: > >> ac_cv_have_foo=no > > > > Here you just overwrite the value obtained above again. > > > >> if test "$ac_cv_use_foo" = &quo

Re: iterating over arguments

* Sam Steingold wrote on Fri, Sep 11, 2009 at 06:24:21PM CEST: > CL_CLISP_REQUIRE_FEATURE([ffi screen unicode]) > and it will expand into something like > > AC_CACHE_CHECK([for FFI in CLISP], [cl_cv_clisp_ffi], > [CLISP_SET(cl_cv_clisp_ffi,[[#+ffi "yes" #-ffi "no"]])]) > test $cl_cv_clisp_ffi = n

Re: Adding an external project to autoconf

* Dan Smithers wrote on Fri, Sep 11, 2009 at 11:57:05AM CEST: > Keith Marshall wrote: > > On Wednesday 09 September 2009 16:02:58 Bob Friesenhahn wrote: > >> the zlib project does not use Autoconf or Automake. It > >> only pretends to look like a project which uses Autoconf or > >> Automake using

Re: caching variables

* Eric Blake wrote on Sat, Sep 12, 2009 at 04:43:01AM CEST: > According to Sam Steingold on 9/11/2009 2:54 PM: > > however, this way I will be testing variables which have never been set. > > is this OK? > > (I understand that unless I set -u, shell will not barf, but I was > > wondering if that wa

Re: iterating over arguments

* Sam Steingold wrote on Sun, Sep 13, 2009 at 05:57:51AM CEST: > > AC_DEFUN([CL_CLISP_REQUIRE_FEATURE], > > [m4_foreach_w([cl_feat], [$1], > > [m4_pushdef([CL_FEAT], m4_toupper(cl_feat))dnl > > AC_CACHE_CHECK([for CL_FEAT in CLISP], [cl_cv_clisp_]cl_feat, > > [CLISP_SET([cl_cv_clisp_]cl_feat, > >

Re: iterating over arguments

* Sam Steingold wrote on Sun, Sep 13, 2009 at 04:30:05PM CEST: > > I'd prefer a small reproducible example (i.e., full configure.ac that > > exposes the issue). > > I am not big on small reproducible examples :-( > however, a small experiment indicates that the problem is with m4_toupper, > see ht

Re: Optional GTK?

* Patrick M. Rutkowski wrote on Mon, Sep 14, 2009 at 03:21:06AM CEST: > If I were to run something like AM_PATH_GTK_2_0 in my configure.ac, > which checks for the presence of GTK, what would I do if GTK wasn't > found? You'd use the ACTION-IF-NOT-FOUND argument of the AM_PATH_GTK_2_0 macro to set

Re: Adding an external project to autoconf

* Dan Smithers wrote on Mon, Sep 14, 2009 at 11:18:53AM CEST: > >> How can I tell autoconf to run the configure without worrying about it? > > > > AC_CONFIG_SUBDIRS([zlib]) > > > will cause zlib/configure to be run if it exists in the source tree. > > I had been using > AC_CONFIG_SUBDIRS(zlib dir

Re: Adding an external project to autoconf

Hello Steffen, * Steffen Dettmer wrote on Mon, Sep 14, 2009 at 12:35:56PM CEST: > On Wed, Sep 9, 2009 at 11:16 AM, Dan Smithers wrote: > > I am trying to add an external project to my autoconf setup. > > Could I add a related question: Yes, but we'd slightly prefer if you started a new thread fo

Re: Adding an external project to autoconf

* Keith Marshall wrote on Tue, Sep 15, 2009 at 01:33:34PM CEST: > On Tuesday 15 September 2009 05:31:04 Ralf Wildenhues wrote: > > > is there a way to have > > > sub-package-specific configure options? > > > > Not easily: the actual option strings as passed to ea

Re: [GNU Autoconf 2.64] testsuite: 180 failed

* Paolo Bonzini wrote on Tue, Sep 15, 2009 at 09:08:25PM CEST: > Can you check if this failure happens intermittently or consistently? Also, which shell and version is /bin/sh, and which version is your libc? Thanks! Ralf

Re: support for non-standard C compilers (without fopen, FILE*, ...)

Hello Steffen, * Steffen Dettmer wrote on Thu, Sep 17, 2009 at 05:12:31PM CEST: > recent versions check if $CC supports fopen, FILE* and so on. This > breaks environments that don't have / libc.a. This is a 2.64 regression and has been fixed since in the git tree:

Re: support for non-standard C compilers (without fopen, FILE*, ...)

* Ralf Wildenhues wrote on Thu, Sep 17, 2009 at 07:50:10PM CEST: > * Steffen Dettmer wrote on Thu, Sep 17, 2009 at 05:12:31PM CEST: > > recent versions check if $CC supports fopen, FILE* and so on. This > > breaks environments that don't have / libc.a. > > This is a 2.

Re: how to support compilers that cannot create executables?

Hello Steffen, * Steffen Dettmer wrote on Thu, Sep 17, 2009 at 05:19:46PM CEST: > when compiling libraries, it technically is not required to have a > compiler to create executables. We might have a lib with unit tests > where the unit tests work on linux and windows only, but not on a > small emb

Re: how to support compilers that cannot create executables?

* Steffen Dettmer wrote on Fri, Sep 18, 2009 at 12:19:19PM CEST: > On Thu, Sep 17, 2009 at 8:20 PM, Ralf Wildenhues wrote: > > * Steffen Dettmer wrote on Thu, Sep 17, 2009 at 05:19:46PM CEST: > >> However, configure usually checks if the compiler can create > >> execut

Re: support for non-standard C compilers (without fopen, FILE*, ...)

* Steffen Dettmer wrote on Fri, Sep 18, 2009 at 11:49:20AM CEST: > On Thu, Sep 17, 2009 at 7:53 PM, wrote: > > * Ralf Wildenhues wrote on Thu, Sep 17, 2009 at 07:50:10PM CEST: > > > * Steffen Dettmer wrote on Thu, Sep 17, 2009 at 05:12:31PM CEST: > > > > recent versio

Re: how to retrieve expanded variables from configure?

Hello, * none none wrote on Fri, Sep 18, 2009 at 08:02:14AM CEST: > im not very familiar with autoconf currently so im not sure my following > assumptions are correct > so, afaik, autoconf and its resulting configure script set many variables > e.g. exec_prefix or bindir, ... > > what i try to ac

Re: AC_DEFUN: default values of optional arguments

* Sam Steingold wrote on Fri, Sep 18, 2009 at 07:49:04PM CEST: > How do I give an optional argument its default value? > e.g., > AC_DEFUN([FOO],[...]) > FOO() should be equivalent to FOO([true]) Use m4_default([$2], [true]). Cheers, Ralf ___ Autoconf

Re: multilib and Makefile regeneration

<http://thread.gmane.org/gmane.comp.gcc.devel/108469> * Paolo Bonzini wrote on Mon, Aug 31, 2009 at 11:53:17PM CEST: > On 08/31/2009 11:11 PM, Ralf Wildenhues wrote: > >The easiest for now would be (3), the coolest, most difficult and > >probably most dangerous one would be

Re: Finding "config.h" in VPATH builds

* David Bruce wrote on Sun, Sep 20, 2009 at 12:43:54AM CEST: > I have a project with all the source files in a src directory just > below trunk, which is where the top level configure.ac and Makefile.am > live. When I run configure, config.h is created at build/config.h. > If I run configure from

Re: how to support compilers that cannot create executables?

* Steffen Dettmer wrote on Mon, Sep 21, 2009 at 10:24:26AM CEST: > On Fri, Sep 18, 2009 at 7:07 PM, Ralf Wildenhues wrote: > > * Steffen Dettmer wrote on Fri, Sep 18, 2009 at 12:19:19PM CEST: > > > But because of the tests it would not make much sense to do so, right? > > &

Re: why not #include "config.h"?

* Steffen Dettmer wrote on Tue, Sep 22, 2009 at 05:06:41PM CEST: > I though this was a kind of lazyness; just used "" and <> > interchangingly without deeper meaning? You can do that only as long as there is at most one header file with that name involved. > I tought correct is: > > - with -I (a

Re: ./configure.lineno: fork: Cannot allocate memory

Hello Pierre, * Pierre wrote on Sat, Sep 19, 2009 at 11:28:20PM CEST: > I built a Linux From Scratch 6.5 yesterday which kind of puts you in the boat of fixing things yourself, no? ;-) > and had no problem doing > "./configure" and "make" under chroot for all the packages. But since my > reboot

Re: ./configure.lineno: fork: Cannot allocate memory

* Pierre wrote on Wed, Sep 23, 2009 at 11:56:56PM CEST: > As adviced, I added "set -x" in the configure script of File-5.03. The > software versions are those of LFS 6.5 > (http://www.linuxfromscratch.org/lfs/view/stable/chapter03/packages.html) > : > - Autoconf-2.64 > - Bash-4.0 Please update bas

Re: ./configure.lineno: fork: Cannot allocate memory

Hello Pierre, please don't top-post, thank you. * Pierre wrote on Fri, Sep 25, 2009 at 09:40:50AM CEST: > > You are right, it seems that expr is broken. Here is the result of the > command you advised : > root:/# expr 426 + 1 > Illegal instruction > > I don't know why I didn't have the problem

Re: Portable way to achieve 'ls -v' ?

Hello Rhys, * Rhys Ulerich wrote on Sat, Sep 26, 2009 at 08:33:34PM CEST: > Any suggestions for how to achieve sort-by-version in a portable way? > 'ls -v' does exactly what I need, but doesn't look to be a standard > argument. Recent Autoconf has m4_version_compare for a comparison at autoconf r

Re: why not #include "config.h"?

* Steffen Dettmer wrote on Wed, Sep 23, 2009 at 11:26:33AM CEST: > On Tue, Sep 22, 2009 at 10:35 PM, wrote: > > * Steffen Dettmer wrote on Tue, Sep 22, 2009 at 05:06:41PM CEST: > > > - with -I (and gcc), #include is not correct but works > > >   anyway, because gcc searches system headers in user

Re: AS_DIRNAME

Hello Peter, * Peter Johansson wrote on Mon, Sep 28, 2009 at 11:24:51PM CEST: > Under weaknesses for `dirname' the manual (v2.64) mentions that one > should use macro AS_DIRNAME instead. The macro seems to do what I > want, but I cannot find it in the manual? Is it safe to use that > macro or shou

silent-rules (was: checking automake version in configure.ac)

[ adding automake@ ] Hello Ralf, * Ralf Corsepius wrote on Tue, Oct 06, 2009 at 05:49:52PM CEST: > a) AM_SILENT_RULES are harmful (I know, you know that I think about > this (mal-) "feature" this way - Working around the issues they are > causing in Fedora packaging is a major nuissance.) Could

Re: autoconf, overriding results

Hi Bruno, slowly digging through all pending messages ... * Bruno Haible wrote on Sun, Oct 04, 2009 at 08:22:44PM CEST: > In > you wrote: > > You are arguing for the developer case, which is fine per se, of course, > > but you a

cache variable documentation (was: Autoconf and Automake support for ObjC++)

* Peter Breitenlohner wrote on Tue, Jul 21, 2009 at 11:26:15AM CEST: > During the last several months I was involved in a complete rewrite of > the TeXlive (formerly teTeX) build system using Automake and modernized > Autoconf. > > In doing so I "had" to use the names of various cache variables, i

Re: autoconf --trace MACROS works for AC_* marcoses only?

Hello Peter, * Peter Volkov wrote on Wed, Sep 30, 2009 at 07:07:03PM CEST: > Does autoconf --trace MACROS works for AC_* marcoses only? No, but autoconf needs to know what a macro is; IOW, it needs to see a macro definition somewhere. > I've tried to > use it to find AM_GNU_GETTEXT_VERSION macro

Re: checking for libraries that link but do not run

* Ben Pfaff wrote on Mon, Oct 05, 2009 at 06:20:47PM CEST: > In GNU PSPP, we have had a number of problems with users who pass > correct "configure" flags to link against a library > (e.g. LDFLAGS='-L/usr/local/lib') but do not pass the correct > flags to let binaries linked against those libraries

Re: Specifying which shell to use

Hello Dan, * Dan Smithers wrote on Thu, Oct 08, 2009 at 05:22:56PM CEST: > Is there a way of specifying the shell to ues when running the configure > scripts? At configure run time? Read `info Autoconf --index CONFIG_SHELL'. > I see that the default configure begins > > #! /bin/sh > > that sp

Re: checking for libraries that link but do not run

* Ralf Wildenhues wrote on Thu, Oct 08, 2009 at 07:27:47AM CEST: > But apart from that, I also think that Autoconf should make it easier > for the developer to state: > > - At this point I require the compile command to be able to link an > executable (AC_PROG_{CC,..} don't

Re: regenerating a script specified in AC_CONFIG_FILES

* Adam Mercer wrote on Thu, Oct 08, 2009 at 08:12:49PM CEST: > As part of the configure process I generate a script, git_version, > from a file git_version.in specified in AC_CONFIG_FILES() so that an > appropriate python interpreter is used. However if I modify the > git_version.in file the git_ve

Re: regenerating a script specified in AC_CONFIG_FILES

* Adam Mercer wrote on Thu, Oct 08, 2009 at 10:02:32PM CEST: > On Thu, Oct 8, 2009 at 13:59, Ralf Wildenhues wrote: > > > Are you using Automake?  If yes, and if the arguments to AC_CONFIG_FILES > > are shell literals, then automake should produce a rule to regenerate &g

Re: link and run a (fortran) program redirecting its stdout/stderr

* Stefano Lattarini wrote on Mon, Oct 12, 2009 at 09:20:04PM CEST: > I have to compile and link a Fortran 77 test program. and then run it > redirecting its stdout/stderr (I need to do so to verify that the `stop' > builtin is silent when called without arguments -- unfortunately this is > not alwa

Re: Specifying which shell to use

Hello Dan, please don't top-post, thank you. * Dan Smithers wrote on Mon, Oct 12, 2009 at 03:32:01PM CEST: > When I use CC=gcc and CXX=g++ the configure works and produces a working > Makefile. > > If I set CC=icc and CXX=icpc then the configure fails as shown below. > On my Ubuntu system /bin/

Re: regenerating a script specified in AC_CONFIG_FILES

* Adam Mercer wrote on Mon, Oct 12, 2009 at 06:21:11PM CEST: > On Thu, Oct 8, 2009 at 16:03, Ralf Wildenhues wrote: > > > Can you post configure.ac and the Makefile.am, or a small example > > package that reproduces the issue? > > I've attached a simple exampl

Re: link and run a (fortran) program redirecting its stdout/stderr

* Stefano Lattarini wrote on Tue, Oct 13, 2009 at 03:22:51PM CEST: > What matters to me is that the *program generated* by the compiler, > when executed, is not too verbose w.r.t. the `stop' builtin. Then you should be able to use AC_RUN_IFELSE. To allow for cross compilation, in the fourth argum

Re: link and run a (fortran) program redirecting its stdout/stderr

* Stefano Lattarini wrote on Tue, Oct 13, 2009 at 08:39:11PM CEST: > At Tuesday 13 October 2009, Ralf Wildenhues wrote: > > * Stefano Lattarini wrote on Tue, Oct 13, 2009 at 03:22:51PM CEST: > > > What matters to me is that the *program generated* by the > > > compiler

Re: How to test if preprocessor defines foobar in macro?

* Dr. David Kirkby wrote on Wed, Oct 14, 2009 at 06:36:36AM CEST: > http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_count_cpus.m4 This macro does not look well-designed. It does the wrong thing when cross-compiling, or even only compiling for a different system (wh

Re: Caching pkgdatadir in configure

* Alberto Luaces wrote on Wed, Oct 14, 2009 at 01:37:33PM CEST: > I wrote a program that uses data files at runtime. I store them in > $pkgdatadir, and it works fine. > > Sometimes I want to execute the program without installing it. I prefer to do this without any recompiling or reconfiguring of

Re: Is there a way to insert a short pause?

* Bob Friesenhahn wrote on Thu, Oct 15, 2009 at 07:59:18PM CEST: > > It would be good if autoconf provided an official way to produce > deferred accumulated warning text displayed the end of the configure > run. What measure would you suggest for the case where more than a screenful of deferred m

Re: Is there a way to insert a short pause?

* Bob Friesenhahn wrote on Thu, Oct 15, 2009 at 08:18:58PM CEST: > If even one warning message is evident at the end of the configure > run, it seems likely that the user will know to scroll back to see > the rest. Unless, of course, that rest is so long that the user won't read it all. There are

Re: Testing platform

Hello David, * Dr. David Kirkby wrote on Thu, Oct 15, 2009 at 11:53:01PM CEST: > I've got this bit of code, which checks for 'bash'. The user does > not need to use the bash shell, but many scripts assume the back > shell and will fail otherwise (no, I did not write them myself!) The first questi

Re: Generating file lists

Hello, * NightStrike wrote on Fri, Oct 16, 2009 at 07:17:49PM CEST: > I want to store a list of files determined at configure time into > shell variable, which then gets substituted into a Makefile.in. So, I > did this: > > SYSHEAD_LIST=$srcdir/include/sys/*.h > AC_SUBST([SYSHEAD_LIST]) > > Tha

Re: AS_VAR_IF and the resulting shell code

Hello, * NightStrike wrote on Fri, Oct 16, 2009 at 06:45:57PM CEST: > xx=yes > AS_VAR_IF([xx],[yes],[echo equal],[echo not equal]) > results in this: > > xx=yes > if test "x$xx" = x""yes; then >   echo equal > else >   echo not equal > fi > with autoconf 2.63. > > How come the right hand side of

Re: Generating file lists

* NightStrike wrote on Fri, Oct 16, 2009 at 07:24:36PM CEST: > On Fri, Oct 16, 2009 at 1:22 PM, Ralf Wildenhues wrote: > >  SYSHEAD_LIST=`echo $srcdir/include/sys/*.h` > > > > or > >  set x $srcdir/include/sys/*.h > >  shift > >  SYSHEAD_LIST="$*"

Re: Testing platform

* Dr. David Kirkby wrote on Fri, Oct 16, 2009 at 12:15:19PM CEST: > Ralf Wildenhues wrote: > >In any case, you should not use $foobar for both; if you need both, have > >two variables, which can default to the same thing. And let your user > >know which is what, and how t

Re: Generating file lists

* NightStrike wrote on Fri, Oct 16, 2009 at 08:51:15PM CEST: > Ok, so I tried to be fancy and do this: > > AS_VAR_APPEND([SYSHEAD_LIST],[AS_ECHO([$srcdir/include/sys/*.h])]) > > But that results in $SYSHEAD_LIST being equal to "printf". Darn. You'd still need to put the AS_ECHO in a `...` comma

Re: recursive configure and some $ac_highest_top_srcdir?

* Steffen Dettmer wrote on Wed, Oct 21, 2009 at 11:26:22AM CEST: > when using recursive configure via AC_CONFIG_SUBDIRS, how to know > (in a sub-configure) where the top directory is? Good question. If your project structure has a variable level of upper configure scripts then, as you describe, y

Re: pkg-config wisdom

* Bob Friesenhahn wrote on Sat, Oct 24, 2009 at 06:33:18PM CEST: > On Sat, 24 Oct 2009, Peter Johansson wrote: > >Is there anything conceptually stopping us from writing a new > >AC_LINK_IFELSE that links using libtool? That would make life > >easier and avoid problems that only occur in configure

AC_SEARCH_LIBS and non-cdecl calling conventions (was: pkg-config wisdom)

* Matěj Týč wrote on Sun, Oct 25, 2009 at 03:05:26PM CET: > There is one big issue with AC_SEARCH_LIBS: If you use a different > calling convention than cdecl (like stdcall, but I don't know, they've > just told me), you will get unresolved symbols if you try to link > without a proper include file

AC_SEARCH_LIBS and non-cdecl calling conventions (was: pkg-config wisdom)

Hello, * John Calcote wrote on Mon, Oct 26, 2009 at 05:46:07PM CET: > On 10/25/2009 8:05 AM, Matěj Týč wrote: > >There is one big issue with AC_SEARCH_LIBS: If you use a different > >calling convention than cdecl (like stdcall, but I don't know, they've > >just told me), you will get unresolved sy

Re: AC_SEARCH_LIBS and non-cdecl calling conventions

* John Calcote wrote on Tue, Oct 27, 2009 at 09:20:44PM CET: > Passing a fully-specified function prototype in the macro is a > reasonable thing to do for the sake of various C++ mangling schemes, > as well as for the sake of other calling conventions that require > the number and/or types of param

Re: link and run a (fortran) program redirecting its stdout/stderr

* Eric Blake wrote on Wed, Oct 28, 2009 at 03:19:37AM CET: > According to Stefano Lattarini on 10/14/2009 3:52 AM: > >> Sorry; I forgot to add: In the ACTION-IF-TRUE argument of > >> AC_RUN_IFELSE, you can invoke ./conftest$EXEEXT yourself and see > >> what it does. > > Oh. This is exactly what I

Re: Getting a list of available C compilers

Hi Harlan, * Harlan Stenn wrote on Tue, Oct 27, 2009 at 12:39:24AM CET: > Does anybody have (a pointer to) a small utility that will return a list > of available C compilers on a system? I guess you can peek at AC_PROG_CC for a list, that is of course far from complete. > Extra points if it can

Re: Getting a list of available C compilers

* Harlan Stenn wrote on Sun, Nov 01, 2009 at 01:09:36AM CET: > If I have a script that will generate the list of unique (more or less, > I expect this will be a bit of a moving target) C compilers, I can: > > for i in `cc-list` > do > build CC=$i > done > > and our "build" script will pro

Re: AC_CONFIG_HEADERS & AC_CONFIG_FILES combo

* Paolo Bonzini wrote on Tue, Oct 20, 2009 at 07:41:12PM CEST: > AC_CONFIG_HEADERS has to have a very specific format. You'd do > > AC_DEFINE_UNQUOTED([LIBFFCALL_VERSION], ["$PACKAGE_VERSION"], >[Version of libffcall, for avcall.h]) > > and in avcall.h.in > > #ifndef LIBFFCA

Re: about the version number of the package

* Vincent Torri wrote on Sun, Nov 01, 2009 at 12:00:13PM CET: > I wanted to write an m4 macro to be put in a lot of our configure.ac > files. The problem is that the code contain '$1' to compute the > parts of the version of the package (major, minor, etc...). The code > is the following: > > VMAJ

Re: Getting a list of available C compilers

* Steffen Dettmer wrote on Tue, Nov 03, 2009 at 02:58:30PM CET: > On Sun, Nov 1, 2009 at 1:49 AM, Ralf Wildenhues wrote: > > names='gcc gcc[0-9_-]* cc c89 c99 cgcc clang llvm-gcc sdcc tcc > >       xlc xlc_r bgxlc icc ecc pgcc pathcc ccc nvcc cl bcc bcc32' > > .

Re: Can't use Fortran 90/95 compiler for F77

Hello Jeff, thanks for the report. * Daily, Jeff A wrote on Tue, Nov 03, 2009 at 09:50:46PM CET: > <> > We use autoconf to build a mixed Fortran 77/C/C++ code and have recently > run into problems using Fortran 90/95 compilers for F77. Our Fortran > source is Fortran 77 and all Fortran 77 sour

Re: Can't use Fortran 90/95 compiler for F77

Hello Jeff, thanks for your reply. Please keep the mailing list in Cc:, so that others can see, too, and please don't top-post. Thanks. * Daily, Jeff A wrote on Wed, Nov 04, 2009 at 05:25:37PM CET: > From: Ralf Wildenhues: > > First, does using > > ./configure F77="f

Re: autoreconf fails when LT_INIT and AC_SUBST are both present in configure.ac

Hello Ilker, * Ilker R Capoglu wrote on Tue, Nov 10, 2009 at 06:54:48PM CET: > I couldn't be sure whether this was a bug or my own doing (which is > more probable), so I decided to post here. This looks like a bug somewhere. I can't reproduce it yet, so: which Perl and M4 versions do you use? >

Re: autoreconf fails when LT_INIT and AC_SUBST are both present in configure.ac

Hello, and thanks for the additional information. * Ilker R Capoglu wrote on Wed, Nov 11, 2009 at 06:33:39PM CET: > >>When I have both LT_INIT and AC_SUBST macros inside my > >>"configure.ac", autoreconf fails: > >>$ autoreconf -vif > >>autoreconf: Entering directory `.' > >>autoreconf: configure.

Re: checking Mac OS X headers

Hello Vincent, * Vincent Torri wrote on Mon, Nov 09, 2009 at 07:45:32PM CET: > I would like to check if some Mac OS X headers are available. So I > first set the Objective C compiler with AC_LANG_PUSH, only if there > is an Objective C compiler: > > # Check compilers > > m4_ifdef([AC_PROG_OBJC],

Re: checking Mac OS X headers

* Vincent Torri wrote on Sat, Nov 14, 2009 at 05:21:00PM CET: > >>m4_ifdef([AC_PROG_OBJC], > >> [ > >>AC_PROG_OBJC > >>_AM_DEPENDENCIES(OBJC) > > > >Is this to support Automake versions before 1.10? Because with 1.10 or > >newer, you should not need to add _AM_DEPENDENCIES(OBJC). > > Ex

Re: compile wrapper script with C++ file

Hi David, and sorry for the long delay, * David Byron wrote on Fri, Nov 13, 2009 at 08:18:35PM CET: > On Friday September 4th, 2009, Eric Blake wrote: > > According to David Byron on 8/14/2009 1:57 PM: > > > I'm not sure whether this is something I'm doing wrong > > > or something wrong with auto

Re: abs_top_srcdir missing from autotest in 2.63

Hello Braden, * Braden McDaniel wrote on Mon, Nov 23, 2009 at 06:20:16AM CET: > It looks like the abs_top_srcdir shell variable is no longer set for > testsuite in Autoconf 2.63. What can I do instead (to refer to a file > in the source tree)? AC_CONFIG_TESTDIR (DIRECTORY, [TEST-PATH = `director

Re: checking Mac OS X headers

Hello Vincent, * Vincent Torri wrote on Sat, Nov 14, 2009 at 08:20:12PM CET: > On Sat, 14 Nov 2009, Ralf Wildenhues wrote: > >>configure:11850: checking whether we are using the GNU Objective C compiler > >>configure:11869: gcc -c conftest.m >&5 > >>gcc:

Re: permissions on autom4te.cache/ ?

[ adding autoconf-patches ] Hello Harlan, thanks for the report. * Harlan Stenn wrote on Sat, Nov 14, 2009 at 08:28:18AM CET: > I'm real careful to set my umask to 2, as it is Important that > directories and files I create are able to be modified by others in the > group. > > autom4te.cache/ i

Re: libpthread check immature and broken

Hello, * kordex - wrote on Fri, Nov 27, 2009 at 04:16:29PM CET: > Yes, doing the wrong thing is most likely to happen when one does not > know the software one is trying to work with. But why does confgure > fail even if there is -lpthread and available on hpux? Presumably (I haven't looked at t

Re: Quick divert() 2.13/2.6x portability macro

* Thomas Dickey wrote on Sat, Nov 28, 2009 at 04:26:58PM CET: > On Sat, 28 Nov 2009, Eric Blake wrote: > > > >Here's a thought. I'm not sure whether the divert's were necessary in > >autoconf 2.13 (that is so old that it pre-dates my involvement with > > 2.13 uses diverts for help-messages, etc.

Re: Quick divert() 2.13/2.6x portability macro

* Rasmus Lerdorf wrote on Sun, Nov 29, 2009 at 09:33:56PM CET: > Ralf Wildenhues wrote: > > > > We looked at a PHP package and its diversion usage for its toplevel > > configure script with Autoconf 2.13 when a bug with PHP and newer > > Autoconf was last reported, with

Re: autoconf-2.65 has 252 test failures on OpenSolaris x86

Hello David, * Dr. David Kirkby wrote on Sun, Nov 29, 2009 at 11:46:52PM CET: > I've got a Sun Ultra 27 running OpenSolaris (06/2009 release). This > is a quad core 3.33 GHz Xeon machine - not a SPARC. [...] > But when I try to build autoconf, there are a large number of > failures. Any ideas what

Re: autoconf-2.65 has 252 test failures on OpenSolaris x86

* Dr. David Kirkby wrote on Mon, Nov 30, 2009 at 11:19:28AM CET: > Ralf Wildenhues wrote: > >* Dr. David Kirkby wrote on Sun, Nov 29, 2009 at 11:46:52PM CET: > >>configure: warning: line 946: " quote may be missing > >>configure: warning: line 955: `...` obsolete, u

Re: autoconf vs

* Ralf Corsepius wrote on Wed, Dec 02, 2009 at 07:05:47AM CET: > On 12/02/2009 04:44 AM, Erik de Castro Lopo wrote: > > configure:18160: checking cstdint usability > > configure:18160: g++ -c -g -O2 -Wall -Wextra -Wsign-compare > > -Wno-ctor-dtor-privacy \ > > -Wno-non-virtual-dtor

Re: question about using AC_SEARCH_LIBS with fortran...

Hi Ed, * Ed Hartnett wrote on Wed, Dec 02, 2009 at 01:26:02AM CET: > I am trying to use the AC_SEARCH_LIBS macro to find a fortran library. I think that should work as expected. > But what if it is installed in a standard location, like /usr/local? > When I test for C libraries, I don't have to

Re: question about using AC_SEARCH_LIBS with fortran...

* Ed Hartnett wrote on Wed, Dec 02, 2009 at 06:41:08PM CET: > Before I continue asking questions about my fortran AC_SEARCH_LIBS > question, let me first make sure I've got it correct for my C library, > because I just recently realized that I've been doing it wrong for > years. No, you haven't.

Re: C99 inline and restrict keyword tests

* Yann Droneaud wrote on Wed, Dec 02, 2009 at 10:32:26AM CET: > Le mardi 01 décembre 2009 à 19:25 +0100, Ralf Wildenhues a écrit : > > * Yann Droneaud wrote on Tue, Dec 01, 2009 at 03:09:11PM CET: > > > If AC_PROG_CC_C99 successfully found a C99 compliant C compiler, >

Re: autoconf vs

* Erik de Castro Lopo wrote on Wed, Dec 02, 2009 at 10:33:05PM CET: > However, one I sort out the problems above, it still doesn't explain > why: > > AC_CHECK_HEADER([cstdint]) > > does result in a HAVE_CSTDINT getting added to the config.h file. We'd need to see the respective parts of conf

Re: GNU Make -v output no longer includes "version"

Hello Dave, * Dave Hart wrote on Sun, Dec 06, 2009 at 07:38:30AM CET: > Having fixed a similar bug in a NTP-local NTP_VPATH_HACK macro, the > following snippet jumped out at me in a configure script from > ntp-4.2.5p250-RC generated with Autoconf 2.65: Thanks for reporting this; but you have arri

Re: Dereference of undefined pointer value in conftest.c

Hello Tomas, * Tomas Carnecky wrote on Sun, Dec 06, 2009 at 09:10:47PM CET: > I just ran the clang static analyzer on the xserver configure script and > it reported a few issues. Most of them were dead assignments/increments, > but there also was one dereference of an undefined pointer value. I >

Re: Dereference of undefined pointer value in conftest.c

Hello Tomas, * Tomas Carnecky wrote on Mon, Dec 07, 2009 at 10:00:43AM CET: > On Dec 7, 2009, at 7:36 AM, Ralf Wildenhues wrote: > > Last time we looked at this code because someone reported oddities, we > > concluded that we shouldn't change the test because we had no

Re: checking Mac OS X headers

* Vincent Torri wrote on Mon, Dec 14, 2009 at 10:54:24AM CET: > > > >I can maybe execute that code if the host is darwin, but it is not > >the standard way of checking features, iirc > > that is, something like: > > if test "x${ac_cv_objc_compiler_gnu}" = "xyes" ; then >AC_LANG_PUSH([Objectiv

Re: Question on check-process / autoconf-2.6.3

Hello Dieter, * Dr. Ing. Dieter Jurzitza wrote on Tue, Dec 29, 2009 at 12:40:35PM CET: > for the begin: you're right, I am not attempting to build 2.6.3 but 2.63 > instead, this was just a typo. Are you trying to build an unmodified version of GNU Autoconf 2.63 or a tarball with distro-specific

Re: checking Mac OS X headers

Hello Vincent, * Vincent Torri wrote on Sat, Jan 02, 2010 at 06:27:49PM CET: > happy new year :-) Same to you. > >>>if test "x${ac_cv_objc_compiler_gnu}" = "xyes" ; then > >>> AC_LANG_PUSH([Objective C]) > >>> AC_CHECK_HEADER([Cocoa/Cocoa.h], > >>> [ > >>> have_quartz="yes" > >>>

Re: zlib

Hello Philip, * Philip Herron wrote on Tue, Jan 05, 2010 at 01:27:32AM CET: > I am having trouble finding some macro or something for my > configure.ac to for zlib support. I found this so far: > http://ac-archive.sourceforge.net/ac-archive/check_zlib.html > But this simply adds the option AC_ARG_

Re: specify AC_INIT version externally

Hello, * esseffe wrote on Mon, Jan 04, 2010 at 05:30:14PM CET: > > What's the easiest way to specify the AC_INIT package version external to > configure.ac? One way is to use m4_esyscmd to use a command that is run at autoconf run time to specify the version. Autoconf's own configure.ac uses th

<    1   2   3   4   5   6   7   8   9   10   >