Re: How to make "configure: WARNING: unrecognized options: --enable-…" an error

On 2024-09-16 09:44, Murrell, Brian wrote: > When an AC_ARG_ENABLE() for a given arg is missing, one only seems to > get a WARNING from configure such as: > > configure: WARNING: unrecognized options: --enable-foo > > Is there any way to make this an error so that configure [ideally, > exits imme

Re: config.status[12]: export: SHELL##: is not an identifier

On 2024-08-06 09:07, Zack Weinberg wrote: > On Mon, Aug 5, 2024, at 10:32 PM, Paul Eggert wrote: >> On 2024-08-05 15:24, Bob Friesenhahn wrote: >>> This one is old and not a "supported" release. It is "omnios- >>> r151030-6484b6d7b5". >> >> If the bug is limited to unsupported releases let's not w

Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE.

On 2024-06-24 10:04, Zack Weinberg wrote: > On Mon, Jun 24, 2024, at 2:56 AM, Nick Bowler wrote: >> I think at the same time it would be worth documenting the AS_LINENO >> functionality, which is the main internal functionality of these >> macros that (unless you just

Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE.

On 2024-06-23 22:23, Zack Weinberg wrote: > I'm thinking of making AC_RUN_LOG, which has existed forever but is > undocumented, an official documented macro ... Yes, please! I will note that Autoconf has a lot of "run and log a command" internal macros with various comments of the form "doesn't w

Re: C23 support in Autoconf

On 2024-04-30 21:59, Jacob Bachmeyer wrote: > Paul Eggert wrote: >> While we're adding to our wishlist that should also be a >> configure-time option, not merely something in configure.ac. That >> way, one could test a tarball's portability without having to modify >> the source code. This is alre

Re: Is it safe to use ax_gcc_builtin to detect __builtin_offsetof?

On 2024-02-25 02:28, Jeffrey Walton wrote: > On Sun, Feb 25, 2024 at 2:09 AM Jeffrey Walton wrote: >> The page >> does not list __builtin_offsetof in the list of documented builtins. >> But the page says "Unsupported built-ins wil

Re: Embed newlines in AC_MSG_* output

Hi, On 2024-01-27 15:46, Dave Hart wrote: > What is the right way to embed newlines in AC_MSG_FAIL or other AC_MSG_* > macros? [...] > I tried: > > AC_MSG_FAILURE( > [--enable-openssl-random was used but no suitable SSL library was\ > found. Remove --enable-openssl-random if you wish to build wi

Re: AT_MTIME_DELAY not working?

On 2023-12-22 09:28, Zack Weinberg wrote: > On Thu, Dec 21, 2023, at 10:07 PM, Jacob Bachmeyer wrote: [...] >> I suggest revising AT_MTIME_DELAY to actually create two files and >> loop touching one of them until the timestamps differ. > > This won’t work, because whether *test* thinks two timesta

Re: Yet another license clarification

On 2023-12-12 14:05, Paul Eggert wrote: > On 12/12/23 06:36, Sergey Kosukhin wrote: [...] >> 2. Some of the macros are refactored versions of the Autoconf macros (NOT >> the >> Autoconf Archive macros). For example, I copied AC_FC_LINE_LENGTH from >> fortran.m4 to a separate file, renamed the macro

Re: How to get autoconf to respect CC="gcc -std=c89"?

On 2023-10-08, Niels Möller wrote: > I would have expected that every input that is valid c89 also is valid > c99, so that support for c99 strictly implies support for c89. But there > may be some corner case I'm not aware of. It is not true in general that a valid C89 program is also valid C99,

Re: Evaluating arithmetic expressions with macros (eval)

Hi, On 2023-10-04, Sébastien Hinderer wrote: > I find myself stuck with something which I assume is trivial. I define: > > m4_define([X], [9]) > m4_define([Y], [3]) > > And I would like to define Z as being the arithmetic sum of X and Y and > can seem to get it. > > I tried several variations of

Re: tcc 0.9.28rc testing: bug in autoconf 2.71 with AC_CHECK_DEFINE

On 24/09/2023, Peter Johansson wrote: > Hi Detlef and Nick, > > On 24/9/23 11:03, Nick Bowler wrote: >> The word AC_CHECK_DEFINE is not found anywhere in the Autoconf >> source code or documentation. > > My guess would be that the 3rd party is the autoconf archive

Re: tcc 0.9.28rc testing: bug in autoconf 2.71 with AC_CHECK_DEFINE

On 2023-09-23, Nick Bowler wrote: > On 2023-09-23, Detlef Riekenberg wrote: >> AC_CHECK_DEFINE(__unix, CFLAGS="-DFOUND__unix $CFLAGS") >> AC_CHECK_DEFINE(__unix__, CFLAGS="-DFOUND__unix__ $CFLAGS") >> AC_CHECK_DEFINE(__linux__, CFLAGS="-DFOUND__lin

Re: tcc 0.9.28rc testing: bug in autoconf 2.71 with AC_CHECK_DEFINE

Hi, On 2023-09-23, Detlef Riekenberg wrote: > During testing of tcc 0.9.28rc, > I found a strange bug in autoconf 2.71 with `AC_CHECK_DEFINE` for > `__unix__`. The word AC_CHECK_DEFINE is not found anywhere in the Autoconf source code or documentation. So I am afraid it is a bit difficult to un

Re: AC_SYS_LARGEFILE

On 2023-09-11, Sébastien Hinderer wrote: > I am writing with a quesiton about the AC_SYS_LARGEFILE macro. > > It would be great to be able to use it but according to its > documentation, the macro adds its flags to the CC output variable, which > is not convenient in my context because we have ded

Re: libtool (use with autotest)

On 2023-07-24, Simon Sobisch wrote: > > I hope to possibly get an answer by moving this question to the > appropriate lists :-) > For more context I provide the original responses to this topic. > > Am 06.07.2023 um 14:55 schrieb Jose E. Marchesi: >> >>> On 2023-07-03 17:16:59 +0200, Bruno Haible

Re: Which Perl versions Autoconf needs [PATCH included]

On 2023-03-30, Zack Weinberg wrote: [...] > Because I don't think anyone else currently active in development has > either the time or the expertise for it. (Just as a data point here, > the oldest version of Perl that I myself have any access to, presently, > is 5.*16*, and I don't know how long

Re: AC_PROG_EGREP and $EGREP_TRADITIONAL and shell conditional statements

On 2023-03-28, Zack Weinberg wrote: > Can someone who understands the problem described at > https://lists.gnu.org/archive/html/autoconf/2022-11/msg00129.html > please construct a minimal, self-contained configure.ac that > reproduces that problem? It is difficult for me to tell whether > anythin

Re: Possible regressions with trunk autoconf (vs 2.71)

On 2022-11-18, Frederic Berat wrote: > The apr program has shown a weird behavior during configure execution: [...] > I found that the problem was actually that "$EGREP_TRADITIONAL" was > undefined during the execution of AC_TYPE_UID_T. > While the corresponding symbol was constructed within a cas

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-10, Zack Weinberg wrote: > The biggest remaining (potential) problem, that I’m aware of, is that > AC_CHECK_FUNC unconditionally declares the function we’re probing for > as ‘char NAME (void)’, and asks the compiler to call it with no > arguments, regardless of what its prototype actual

Re: Generating configuration files conditionnally?

On 2022-06-16, Sébastien Hinderer wrote: > Is it possible to have the META files produced from META.in files but > only if the package they describe has been enabled? There should be no problem using AC_CONFIG_FILES conditionally. For example: % cat >configure.ac <<'EOF' AC_INIT([test], [0])

Re: Parallelization of shell scripts for 'configure' etc.

On 14/06/2022, Nick Bowler wrote: > On 2022-06-14, Michael Orlitzky wrote: >> On Mon, 2022-06-13 at 15:39 -0700, Paul Eggert wrote: >>> >>> I've wanted something like this for *years* (I assigned a simpler >>> version to my undergraduates but of cou

Re: Parallelization of shell scripts for 'configure' etc.

On 2022-06-14, Michael Orlitzky wrote: > On Mon, 2022-06-13 at 15:39 -0700, Paul Eggert wrote: >> >> I've wanted something like this for *years* (I assigned a simpler >> version to my undergraduates but of course it was too much to expect >> them to implement it) and I hope some sort of paralleliz

Re: make check to test a few tests, not all

Hi, On 2022-05-19, Mike Fulton wrote: > I am working through some bugs porting autoconf to z/OS and I'd like to run > the testsuite with just a particular test (e.g. 318). > For my scripts, my preference would be to do this via 'make check' instead > of running the testsuite directly. You can pa

Re: Detecting gated functions w/ AC_CHECK_FUNCS()

Hi, On 2022-05-02, Philip Prindeville wrote: > I was wondering how to do discovery of functions like open_memstream() which > is only exposed by when compilation used -D_GNU_SOURCE or > -D_POSIX_C_SOURCE=200809L. The "normal way" is to just use the AC_USE_SYSTEM_EXTENSIONS macro early in your c

Re: portability of xargs

On 2022-02-14, Mike Frysinger wrote: > context: https://bugs.gnu.org/53340 > > how portable is xargs ? like, beyond POSIX, as autoconf & automake both > support non-POSIX compliant systems. i want to use it in its simplest > form: `echo $var | xargs rm -f`. As far as I can tell xargs was introd

Re: abs_top_srcdir broken?

On 2021-10-18, Sébastien Hinderer wrote: > Given the follwing configure.ac script: > > AC_INIT([demo], [demo], [0.1], [d...@demo.org]) > AC_MSG_NOTICE([abs_top_srcdir="$abs_top_srcdir"]) > > [The] configure script produced by autoconf 2.69 prints: > > configure: abs_top_srcdir="" > > Is that an ex

Re: Description not expanded in a call to AC_DEFINE

On 2021-08-31, Sébastien Hinderer wrote: > Many thanks for your prompt and helpful response! > > So in my case, the file in question is called "version.h", so am I thus > correct that the description mechanism will not work and that I better > put the comments, if any, in version.h.in? Yes, if yo

Re: Description not expanded in a call to AC_DEFINE

Hi Sébastien, On 2021-08-31, Sébastien Hinderer wrote: [...] > As the next step, I wanted to add a description as the third argument, > hoping to find this description in the generated header file as > documented, but that does not work. I did cleanupu the project to make > sure the ancient gener

Re: m4 macro expansion problem

On 2021-08-23, Nick Bowler wrote: > However, you might not notice that this text went unexpanded in > Autoconf (which is in effect while processing aclocal.m4) is KILL, > so all resulting text is simply discarded. Erm, I appear to have accidentally some words... I meant to say &qu

Re: m4 macro expansion problem

On 2021-08-23, Sébastien Hinderer wrote: > I would like to express all this in m4, more precisely in aclocal.m4, so > that the configure script has proper version information. > > At the moment I don't manage to do so and failed to find an exemple of a > macro whose body can take several lines but

Re: Running autoconf and autoreconf without autotools in the path

On 2021-07-20, Christopher O Cowan wrote: >> On Jul 19, 2021, at 2:05 PM, Christopher O Cowan >> wrote: >> Just curious if there is a feature within autotools to allow me run >> autoconf and similar utilities via an absolute path, without the autotools >> suite commands, in the PATH. Maybe this

Re: Force 32 bit build

On 2021-05-06, aotto wrote: > I want to write a "autoconf/automake" script for an application ONLY for > 32 bit on 64 bit Linux. > This meant that the default for configure must be 32 bit and nothing else. > > I know that a user can do "configure CC="gcc -m32"... etc but this is > NOT what I want.

Re: Latest M4 fails M4 checks

On 2021-04-20, Jeffrey Walton wrote: > On Tue, Apr 20, 2021 at 7:00 AM Jeffrey Walton wrote: >> >> I'm working on an Apple Mac-mini M1. I installed M4 1.4.18 in /usr/local. >> >> % /usr/local/bin/m4 --version >> zsh: abort /usr/local/bin/m4 --version >> % /usr/local/bin/m4 -V >> zsh: abort

Re: config.sub/config.guess using nonportable $(...) substitutions

On 09/03/2021, Warren Young wrote: > On Mar 9, 2021, at 1:26 PM, Paul Eggert wrote: >> >>> 1) There is no actual benefit to using $(...) over `...`. >> >> I disagree with that statement on technical grounds (not merely cosmetic >> grounds), as I've run into real problems in using `...` along with

Re: config.sub/config.guess using nonportable $(...) substitutions

On 2021-03-08, Tim Rice wrote: > On Mon, 8 Mar 2021, Nick Bowler wrote: [...] >> These scripts using $(...) are incorporated into the recently-released >> Automake 1.16.3, which means they get copied into packages bootstrapped >> with this version. So now, if I create a pac

config.sub/config.guess using nonportable $(...) substitutions

Hi, I noticed that config.sub (and config.guess) scripts were very recently changed to use the POSIX $(...) form for command substitutions. This change is, I fear, ill-advised. The POSIX construction is widely understood to be nonportable as it is not supported by traditional Bourne shells such

Re: RFC: Bump minimum Perl to 5.18.0 for next major release of both Autoconf and Automake

On 2021-02-18, Karl Berry wrote: > I think the right thresholds are 5.10 for absolute minimum and 5.16 > for 'we aren't going to test with anything older than this' > > I appreciate the effort to increase compatibility with old versions. > > I imagine you could provide Digest::SHA "interna

Re: RFC: Bump minimum Perl to 5.18.0 for next major release of both Autoconf and Automake

Hi Zack, On 2021-02-17, Zack Weinberg wrote: > On Fri, Jan 29, 2021 at 5:54 PM Karl Berry wrote: >> But, I think it would be wise to give users a way to override the >> requirement, of course with the caveat "don't blame us if it doesn't >> work", unless there are true requirements such that not

Re: Weird behaviour about system types

Hi Sébastien, On 2021-02-04, Sébastien Hinderer wrote: > Actually I find it odd that Debian installs cross-compilers under names > that do not have the canonical system type as prefix. > > I can evenseee this line in my configure script: > > test -n "$host_alias" && ac_tool_prefix=$host_alias- >

Re: Weird behaviour about system types

Hi Sébastien, On 2021-02-04, Sébastien Hinderer wrote: [...] > I am calling the generated configure script as follows: > > ./configure --build=x86_64-pc-linux-gnu --host=aarch64-linux-gnu > > I am getting the following output: > > checking build system type... x86_64-pc-linux-gnu > checking hos

Re: Automake's file locking

On 2021-02-03, Bob Friesenhahn wrote: > GNU make does have a way to declare that a target (or multiple > targets) is not safe for parallel use. This is done via a > '.NOTPARALLEL: target' type declaration. According to the manual[1], prerequisites on .NOTPARALLEL target are ignored and this will

Re: couple notes about post-2.71 branch management

Hi Zack, On 2021-01-29, Zack Weinberg wrote: > Finally, to help us keep the development series on branch and trunk > straight, I tagged the "post-release administrivia" commit on the > trunk as v2.72a and on the branch as v2.72b. This will make the > output of autoconf --version be obviously dif

Re: version string comparison

On 2021-01-30, Thien-Thi Nguyen wrote: > In GNUnet configure.ac, there is the fragment: > > # test for libunistring > gl_LIBUNISTRING > AS_IF([test "x$gl_libunistring_hexversion" = "x" || test > "$gl_libunistring_hexversion" -le 2305], >[AC_MSG_ERROR([GNUnet requires libunistring >= 0.9

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

On 2021-01-28, Zack Weinberg wrote: > There is a potential way forward here. The *only* place in all of > Autoconf and Automake where XFile::lock is used, is by autom4te, to > take an exclusive lock on the entire contents of autom4te.cache. > For this, open-file locks are overkill; we could inste

Re: Future plans for Autotools

On 2021-01-25, John Calcote wrote: > On Mon, Jan 25, 2021 at 12:26 PM Nick Bowler wrote: >> On 2021-01-25, Zack Weinberg wrote: >> > I'm not at all familiar with Automake's internals, but the reason I >> > suggested taking advantage of GNU make extensions wa

Re: Future plans for Autotools

On 2021-01-25, Zack Weinberg wrote: > I'm not at all familiar with Automake's internals, but the reason I > suggested taking advantage of GNU make extensions was the potential > for _complexity_ reduction of the generated Makefile, not performance. > For instance, this generated rule from one of m

Re: Autoconf/Automake is not using version from AC_INIT

On 2021-01-24, Peter Johansson wrote: > I've managed to reproduce the behavior Bob describes in the attached > script. If we touch the timestamp of configure.ac, running autoconf will > update the timestamp of configure. But if the autoconf is triggered by > something else for example if ChangeLog

Re: Future plans for Autotools

As always, thanks for all your effort Zack! I wanted to share some of my thoughts on Autoconf and friends. Maybe I wrote too much. For me the most important requirement of the GNU build system is that it must be as straightforward as possible for novice users to build free software packages from

Re: Building a cross-compiler

On 2021-01-20, Sébastien Hinderer wrote: > I am in charge of making cross-compilation possible for the OCaml > language, given that the compiler's build system uses autoconf. The > compiler is written in OCaml itself and has a runtime written in C. > > To start experimenting, I am trying to build

Re: Expansion of @libexecdir@ in .desktop.in file includes ${exec_prefix}

On 2021-01-19, Eli Schwartz wrote: > On 1/18/21 11:24 PM, Nick Bowler wrote: >> This is the only way to make your package follow the GNU coding >> standards, which says users must be able to override these variables >> on the make command line. For example: >> >&

Re: Expansion of @libexecdir@ in .desktop.in file includes ${exec_prefix}

On 2021-01-18, Stefan Koch wrote: > The line: > Exec=@libexecdir@/usbauth-notifier/usbauth-notifier > > from > https://github.com/kochstefan/usbauth-all/blob/master/usbauth-notifier/data/usbauth-notifier.desktop.in > > will expanded to: > Exec=${exec_prefix}/libexec/usbauth-notifier/usbauth-notifi

Re: Getting srcdir in script executed using m4_esyscmd in AC_INIT

On 2021-01-05, Bob Friesenhahn wrote: > Something I found which surprised me is that Automake has added a GNU > COPYING file to my non-GNU non-GPL package. Once the file appeared in > the source directory, it seems that it continued to be used and > included in spite of the Automake options provi

Re: determine base type of a typedef

On 2020-10-23, Nick Bowler wrote: > On 23/10/2020, Paul Eggert wrote: >> On 10/22/20 6:09 PM, Russell Shaw wrote: >>> else if(sizeof(time_t) == sizeof(long int)) { >> >> This is not the right kind of test. You want to test whether time_t and >> int &

Re: determine base type of a typedef

On 23/10/2020, Paul Eggert wrote: > On 10/22/20 6:09 PM, Russell Shaw wrote: >> else if(sizeof(time_t) == sizeof(long int)) { > > This is not the right kind of test. You want to test whether time_t and int > are > the same types, not whether they're the same size. To do that, you should > use

Re: Weird failure with autoconf 2.69c in gmp

On 2020-10-14, Ross Burton wrote: > No it's the # in the URL. Simply removing #libidn2 fixes this problem. > > Presumably some quoting problem which just needs more precision []? [...] > On Wed, 14 Oct 2020 at 09:26, Ross Burton wrote: >> >> Similar in libidn2: >> >> | m4:configure.ac:16: Warning

Re: Weird failure with autoconf 2.69c in gmp

On 13/10/2020, Ross Burton wrote: > Hi, > > Using autoconf 2.69c (upgrading from 2.69b meant we could drop two > patches, so that's good news!) to build gmp fails in a rather > mysterious way: [...] > | m4:configure.ac:40: Warning: excess arguments to builtin `m4_define' > ignored > | autom4te: er

Re: [PATCH v2] Ensure standard file descriptors are open on start

On 2020-08-28, Paul Eggert wrote: > On 8/28/20 6:52 AM, Zack Weinberg wrote: >> I think that for 2.70 we should make fd 0 read-only and 1,2 >> write-only here, and revisit this afterward -- when we're not in a >> release freeze we can think about things like turning on set -e mode. > > Sounds good

Re: Exactly when does autoconf enter cross-compilation mode?

On 2020-08-23, wf...@niif.hu wrote: > Nick Bowler writes: >> On 2020-08-22, wf...@niif.hu wrote: >> >>> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html [...] > The documentation linked above is confusing beca

Re: Exactly when does autoconf enter cross-compilation mode?

On 2020-08-22, wf...@niif.hu wrote: > https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html > is rather hard to follow in general, but also contains the following > clear-cut statement: "Now, configure enters cross-compilation mode if > and only

Re: Using @bindir@ etc. in C headers

On 05/06/2020, Florian Weimer wrote: > * Nick Bowler: > >>> It would like to get config.status expansion going, among other things. >>> It's nice to consolidate these things in a single place, and avoid >>> scattering such constructs and several places

Re: Using @bindir@ etc. in C headers

On 05/06/2020, Florian Weimer wrote: > * Michael Orlitzky: > >> On 6/5/20 6:57 AM, Florian Weimer wrote: >>> I would like to define macros containing the standard paths, like this: >>> >>> #define BINDIR "@bindir@" >>> >>> It does not work due to this code in lib/autoconf/general.m4 (which >>> app

Re: New failures with autoconf master

On 18/03/2020, Nick Bowler wrote: > On 2020-03-18, Ross Burton wrote: > [...] >> The flex issue is worked around by picking this commit from flex git: >> >> https://github.com/westes/flex/commit/c42de062bbdc7c31d7181c10a74202d493280ada >> >> That refers to a m

Re: New failures with autoconf master

On 2020-03-18, Ross Burton wrote: [...] > The flex issue is worked around by picking this commit from flex git: > > https://github.com/westes/flex/commit/c42de062bbdc7c31d7181c10a74202d493280ada > > That refers to a mail sent to bug-autoconf in February 2018, with no reply: > > https://lists.gnu.o

Re: gl_CACHE_VAL_SILENT won't work correctly with upcoming autoconf 2.70

On 2020-03-13, Paul Eggert wrote: > On 3/13/20 3:04 PM, Nick Bowler wrote: >>AS_VAR_SET_IF([my_cv_no_printing], [my_cv_no_printing=hello]) > > I assume you meant > >AS_VAR_SET_IF([my_cv_no_printing], [], [my_cv_no_printing=hello]) Yes, thank you for the correction. Cheers, Nick

Re: gl_CACHE_VAL_SILENT won't work correctly with upcoming autoconf 2.70

Hi Bruno, On 13/03/2020, Bruno Haible wrote: > The underlying problem in Autoconf is the following: There is a macro > AC_CACHE_CHECK that does messaging, and a macro AC_CACHE_VAL whose > main purpose is to make a cache lookup, not messaging, but it > nevertheless outputs '(cached)' strings occas

Re: Why autoreconf complains about missing AM_GNU_GETTEXT

On 2020-02-11, Jan Palus wrote: > error "$configure_ac: AM_GNU_GETTEXT_VERSION is used, but not > AM_GNU_GETTEXT" > if $uses_gettext && ! $uses_gettext_via_traces; > > Mentioned AM_GNU_GETTEXT implies additional checks for C compiler, linker > and gettext symbols availability which are compl

Re: No macro for C11/C18?

On 2020-02-01, Andrew W. Nosenko wrote: > On Fri, Jan 24, 2020 at 9:48 PM Nick Bowler wrote: > > AC_PROG_CC now tries to select the highest language revision supported > > by the compiler. > > These macros (AC_PROG_CC_C99 vs. new AC_PROG_CC) have different > semantics.

Re: No macro for C11/C18?

On 2020-01-24, Christian Biesinger wrote: > On Fri, Jan 24, 2020 at 8:47 PM Nick Bowler wrote: >> AC_PROG_CC now tries to select the highest language revision supported >> by the compiler. > > Nice. Is there a way to query what language revision it found, so that > con

Re: No macro for C11/C18?

On 1/24/20, Christian Biesinger wrote: > I noticed that autoconf has a macro to enable C99 (AC_PROG_CC_C99), > but apparently no such macro for C11 or C18. I was wondering if a > patch for that would be acceptable in principle or if this is missing > intentionally? In autoconf master, the AC_PROG

Re: Conventions on build variables

On 8/26/19, Sébastien Hinderer wrote: > Similarly, I kind of remember that if, say, make install is invoked with > a different value of PREFIX that value must be taken into acocunt and > that it is required that PREFIX can have different values during make > and make isntall. I am wondering whethe

Re: Using AC_DEFINE with AC_ARG_ENABLE (or AC_ARG_WITH)

Hi Chris, On 8/15/19, Chris Packham wrote: > I'm trying to get a value provided on the ./configure invocation > through to C code so it can be used. I'm trying to do this with > AC_DEFINE but maybe this is a job for something else. [...] > AC_DEFINE([ENTITY],[${enable_entity}],[Entity]) [...] > I

Re: autotest/AT_CHECK: ways to pass additional options on to diff?

On 2019-04-25, Jannick wrote: > But there is an elegant solution to that, whereas in the beginning I was > too 'narrow-minded' because of the host of information about the autoconf > machinery I had to process and to cope with: simply offer autotest a > customized script called 'diff' - surprise s

Re: autotest/AT_CHECK: ways to pass additional options on to diff?

On 4/16/19, Jannick wrote: > I am wondering if there is an elegant way to pass additional diff options > on to AT_CHECK in a testsuite - ideally on the level of .ac, .am, .at files > or alike? [...] > configure translates this code snip into the script testsuite where - and > this is really evil h

Re: AC_PROG_CC’s recommendation for “: ${CFLAGS=""}”

Hello, On 2019-03-08, Дилян Палаузов wrote: > the Autoconf manual states for “Macro: AC_PROG_CC ([compiler-search-list])”: > > “If using the GNU C compiler, set shell variable GCC to ‘yes’. If output > variable CFLAGS was not already set, set it to -g -O2 for the GNU C compiler > (-O2 on systems

Re: Arguments to configure

Hello, Responding to part of your message... On 2018-10-03, Sébastien Hinderer wrote: > In the same vein, I was wondering why the 'AC_SYS_INTERPRETER' macro > doesn't come in three variants, one for build, one for host and one for > target because I imagine that one may want to know whether #! i

Re: cl.exe and system types

Hi Sébastien, On 2018-08-21, Sébastien Hinderer wrote: > What I do not understand, though, is why it is necessary to specify > --build. I know the manual says that when one specifies --host then one > has to specify --build, too, for historical reasons, but the manual also > says that this will b

Re: Cross-platform "warning is an error" with Autoconf?

On 8/4/18, Peter Johansson wrote: > On 8/3/2018 9:38 AM, Jeffrey Walton wrote: >> If I change to CXXFLAGS="-Werror" then MSC and other Windows compilers >> incorrectly reject the program. >> >> I think the root cause of the problem is, I need a cross-platform way >> to say "treat warnings as error

Re: How to write directly to config.h from configure?

On 7/26/18, Jeffrey Walton wrote: > I have a bad interaction with a project and Autotools. The project is > not an Autotools project but we are trying to [cleanly] support > Autotools. The project provides its own config.h since the mid-1990's. > We want to supply roughly the same file though Auto

Re: unable to escape ! in autotest stdout comparison text

On 2018-05-29, John Calcote wrote: > I'm trying to create a test using autotest that compares the stdout of my > program with a string. Unfortunately, the output of the program contains > the path of the program. As part of its output, it writes its own program > name (from argv[0]) to stdout, so

Re: Autoconf protype breaks GCC builtin inlining

On 1/25/18, Ferenc Wágner wrote: > Jeffrey Walton writes: > >> AC_MSG_CHECKING([if $LDNAME supports $LDFLAGS]) >> AC_COMPILE_IFELSE([AC_LANG_PROGRAM([])], >> [AC_MSG_RESULT([yes]); AC_SUBST([tr_RESULT], [1])], >> [AC_MSG_RESULT([no]); AC_SUBST([tr_RESULT], [0])] >> ) > > Thanks for the

Re: m4_map and AC_REQUIRE hoisting

Hi Eric, On 1/24/18, Eric Blake wrote: > On 01/24/2018 12:32 AM, Nick Bowler wrote: >> Hello Autoconfers, >> >> I hit a weird (to me) issue involving m4_map(all) and AC_REQUIRE, and I >> would appreciate some help understanding what's going on here! > >

m4_map and AC_REQUIRE hoisting

Hello Autoconfers, I hit a weird (to me) issue involving m4_map(all) and AC_REQUIRE, and I would appreciate some help understanding what's going on here! So normally when expanding a macro defined with AC_DEFUN and a nested AC_REQUIRE causes a macro to be expanded, that expansion gets "hoisted" o

Re: How to deal with test data in ouf of source tree builds?

Hello Paul, On 2017-06-15, Paul Menzel wrote: > When doing an out of source build of Unbound, the test suite fails [...] > In the source directory there is a directory `testdata`, and that gets > referenced incorrectly in `testcode/unitverify.c`. [...] > verifytest_file("testdata/test_si

Re: Proper location to install shell function libraries?

On 3/1/17, Ralf Corsepius wrote: > On 03/01/2017 05:13 PM, Nick Bowler wrote: >> The definition of these install variables comes from the GNU Coding >> Standards[1]. You mention the installed scripts are machine-dependent >> so they should be installed in either libdir or

Re: Proper location to install shell function libraries?

Hello, On 3/1/17, Andreas Kusalananda Kähäri wrote: [...] > The scripts make use of a common set of shell functions, defined in > their own file. This is currently sourced like this: > > prefix="@prefix@" > exec_prefix="@exec_prefix@" > . "@libexecdir@/toolbox.shlib" > > Then, in the

Re: AC_HEADER_MAJOR vs. glibc 2.25(-to-be)

On 8/31/16, Zack Weinberg wrote: > glibc 2.25 is going to deprecate the definition of 'major', 'minor', > and 'makedev' by sys/types.h; see > https://sourceware.org/bugzilla/show_bug.cgi?id=19239 for rationale. > (It was found to be impractical to remove sys/types.h from stdlib.h.) > Unfortunatel

Re: Conditionally including macros that require a newer autoconf version

On 2016-07-26, Rainer Gerhards wrote: > I want to add the AX_COMPILE_FLAGS macro to my projects in order to > produce better code. Unfortunately, this macro (more precise: it's > helpers) require at least autoconf 2.64. This is not available on a > number of platforms, Centos 6 is an example (2.61

Re: OPENMP_FLAGS in autoconf not working

Hello, On 6/23/16, Rudra Banerjee wrote: > I am trying to compile a fortran code with gnu-autotools. The openmp > specific lines in configure.ac is: > > AC_OPENMP > AC_PROG_FC([gfortran]) > FCFLAGS="$OPENMP_FFLAGS -fcheck=all" The tests performed by AC_OPENMP (and the variables set) depend on th

Re: $sysconfdir substitution

On 6/10/16, Kip Warner wrote: > Thanks for the suggestion. Unfortunately I've already got access to the > variable through the pre-processor (e.g. AM_CPPFLAGS), but I need the > variable substituted in a non-compiled .in file with AC_CONFIG_FILES. It would be possible to make this work by writing

Re: Call the AC_CHECK_HEADER macro on a condition

Hi, On 2016-04-12, YuGiOhJCJ Mailing-List wrote: [snip exposition] > So, I would like to call the AC_CHECK_HEADER macro on a condition: > AC_INIT([my-project], [20160412]) > AM_INIT_AUTOMAKE > AM_PROG_CC_C_O > if test "x$host" == xavr; then > AC_CHECK_HEADER([avr/io.h], [], [AC_MSG_ERROR([m

Re: Transferring variables from configure.ac to Makefile.am

Hi Russell, On 3/24/16, Russell Wallace wrote: > I think I sort of see how to set variables within configure.ac, and do some > minimal calculations on them. But how do you transfer the value of a > variable set in configure.ac, to Makefile.am where it will be actually > used? Any shell variable

Re: Compiling for newer Intel CPUs with an older Intel build system?

On 2016-03-04, Sean Byland wrote: > On 3/4/16, 12:24 PM, "Nick Bowler" wrote: >>On 2016-03-04, Sean Byland wrote: [...] >>> 2. Generating a config.cache on the Ivybridge compute node, which >>> shares the majority of the file system with the Sandybridge sy

Re: Compiling for newer Intel CPUs with an older Intel build system?

On 2016-03-04, Sean Byland wrote: > I’m trying to help users get autotools-based projects to compile in our > somewhat unique environment. It’s fairly common for users to want to compile > on a Intel ivybridge system (node) with Intel broadwell-specific (a superset > of CPU instructions) performan

Re: C11 and C++11 support detection fails with clang

On 2016-02-24, Mike Miller wrote: [...] > The C11 feature tests fail with the following: > > conftest.c:191:19: error: static_assert expression is not an integral > constant expression > _Static_assert (&v1.i == &v1.w.k, "Anonymous union alignment botch"); > > This seems like a valid diagnos

Re: Cross-compiling with Autoconf

On 11/2/15, Dustin Laurence wrote: > Situation: I need to cross-compile an autoconfiscated library [...] > LONG_ARCH = strongarm > > ./configure \ > --build=`./build-aux/config.guess` \ > --host $(LONG_ARCH)-codesafe-elf \ > CC="/opt/nfast/gcc/bin/$(LONG_ARC

Re: How to programmatically detect awk flavor (e.g. gawk vs mawk vs nawk vs awk)

Hi, On 10/18/15, Itamar Gal wrote: > I recently posted a question to unix.stackexchange.com asking for the best > way to programmatically determine which flavor of awk is present on a given > host. > > Someone suggested using the AC_PROG_AWK macro, but didn't elaborate on how > this would work.

Re: How can I always cross compile even when host and build are the same?

On 2015-08-31 17:49 +, Steven Stewart-Gallus wrote: > I would prefer to never invoke runtime tests such as for whether vfork is > effective and simply always cross compile even if host and build are the same > (I > want people cross compiling from some other architecture to obtain the exact >

Re: macro which returns found compiler for given language?

x27;d be much cleaner if one could get the compiler for the > current language, or have _AC_CC exposed as part of the public API. There is AC_LANG_CASE: AC_LANG_CASE( [Fortran], [...do stuff with $FC], [Fortran 77], [...do stuff with $F77], [neither option]) It seems this fun

Re: Check whether AC_PROG_X has failed

[std::cout << "Hello, World" << std::endl;])], [my_cv_cxx_works=yes], [my_cv_cxx_works=no])]) AS_IF([test x"$my_cv_cxx_works" != x"yes"], [AC_MSG_ERROR([sorry, can't help you])]) Perhaps AC_PROG_CXX would be improved by simply performing a test like th

  1   2   >