autoconf-generated configure scripts substitute strings like @var@ in files
like for the value of output variables set in the configure script. Most of
the time, these will only be used in lines like
var = @var@
in Makefile.in. The Makefile.in may have many of these lines. In fact,
automake scans
Thanks, your suggestion works.
I'm not sure if what you say about automake would be true of any kind
of Makefile generator which did what automake did, but I'm still
experimenting with alternatives.
On Mon, Apr 1, 2013 at 3:23 PM, Nick Bowler wrote:
> On 2013-03-30 14:56 +
ing the assignments that emanate from autoconf? (I understand
that it is done, and stopping it being done would be
backwards-incompatible.) Also on tests I did, if a variable was
defined multiple times in a makefile, make took the definition that
occurred latest in the file, so overriding definitions is p
On Tue, Apr 23, 2013 at 10:51 AM, A.P. Horst wrote:
> Is there a possibility to preserve the generated source and output file
> generated by the many tests a configure does? In particular the "checking
> for dependency style of [compiler]" does a lot of tests, but it is very hard
> to find out wha
On Sun, May 19, 2013 at 9:57 AM, Kip Warner wrote:
> Hey list,
>
> I have my message catalogues in a directory in my project other than in
> the usual po/. I ran gettextize --po-dir=folder. I also updated
> Makevars's subdir to point to the new directory. The SUBDIRS variable in
> my Makefile.am a
On Mon, May 20, 2013 at 8:05 PM, Kip Warner wrote:
>> Without seeing your actual Makefile.am, I can only guess that perhaps
>> you made your EXTRA_DIST conditional? I've been bitten by that in some
>> of my own projects, where a conditional EXTRA_DIST impacts what goes
>> into the tarball accordi
On Thu, Jun 6, 2013 at 8:08 PM, Nicolas Bock wrote:
> Hi,
>
> The C++ compiler I am using (charmc) needs an additional command line
> argument during the linker stage (-language charm++). I am unsure how to
> best add this argument. The generated makefiles use CXX for compilation and
> CXXLD for l
On Fri, Jun 7, 2013 at 1:03 AM, Peter Johansson wrote:
> I maintain a library that uses boost heavily. Recently I learnt that
> is broken with certain version of GCC (4.4.7 for
> example). I would like provide a workaround for users of the library (myself
> e.g.) so we won't even notice the break
On Mon, Sep 30, 2013 at 8:56 AM, Harlan Stenn wrote:
> I've got a situation where I want to track specific libraries that are
> needed for building specific programs. Sometimes this is for things
> like openssl and sometimes it's network stuf or thread stuff, where I
> know which programs need it
>> Could you use a "--with" flag using AC_ARG_WITH and run AC_CHECK_LIB
>> only if the library was enabled?
>
> That's not the problem.
>
> The problem is that:
>
> - we think we cannot put all libraries in LIBS. Therefore...
>
> - we put certain libraries in FOO_LIBS which is then not "seen" by t
On Tue, Mar 11, 2014 at 5:00 PM, Jim Galarowicz wrote:
> Hi Eric, Patrick, all,
>
> I made those changes also. Here is what I have in the two m4 files now (for
> that area).
>
> m4/ax_qt3.m4:
>
>450if test $found_all_qt -eq 1; then
>451 AC_DEFINE(HAVE_QTLIB, 1, [Define to
On Tue, Mar 11, 2014 at 9:43 PM, Jim Galarowicz wrote:
>
> The ] and ) at 456 are the terminators for the AC_DEFUN declaration. That
> (big bold characters) is where they go to when I do the % key when on the
> two characters at 456.
>
> AC_DEFUN([AX_QTLIB], [
> dnl if QTDIR is not default to /us
On Wed, Mar 12, 2014 at 2:34 PM, Jim Galarowicz wrote:
> Hi Gavin, all,
>
> I ran the
>
> autoconf --trace AM_CONDITIONAL command in the bootstrap instead of just
> autoconf and here are the results.
It could be a problem with aclocal. You said that your bootstrap script worked:
aclocal --force
On Sun, Mar 23, 2014 at 12:24 AM, John Spencer
wrote:
> there are many configure scripts out there that still check for things that
> are standard since at least 10 years, and doing this extensively and over
> and over (people building software themselves usually build more than one
> package) con
On Thu, Sep 4, 2014 at 9:33 PM, Nick Bowler wrote:
> Quoted from the linked page:
>> After some investigation, I discovered that the documentation for GNU
>> AutoTools was crappy. This is surprising considering how long it has
>> been in use. ☹
>
> Can you be more constructive? I think Autoconf a
On Fri, Sep 12, 2014 at 6:10 PM, Shawn H Corey wrote:
> No, it's not a "natural" attitude. I have worked on open-source
> projects where this attitude is not present and on proprietary ones
> which had it in spades. It depends on the people involved. And it also
> drives people away from open-sour
On Sat, Sep 13, 2014 at 4:32 PM, David A. Wheeler wrote:
> There *are* good tutorials available for the autotools.
> John Calcote's book is awesome, I highly recommend it.
> The "Goat book" ("GNU Autoconf, Automake, and Libtool" by Gary V. Vaughn and
> Ben Elliston)
> was great for its time; if
I got it down to the use of AC_DEFUN_ONCE in the definition of
AC_USE_SYSTEM_EXTENSIONS. If configure.ac is
AC_DEFUN_ONCE([AC_USE_SYSTEM_EXTENSIONS_TEST],
[ echo here
])# AC_USE_SYSTEM_EXTENSIONS
AC_PREREQ([2.63])
AC_INIT([bug], [0.01])
# X
On Tue, Nov 18, 2014 at 3:38 AM, Harlan Stenn wrote:
> Eric Blake writes:
>> On 11/16/2014 11:51 PM, Harlan Stenn wrote:
>>> One installation directory choice I haven't found a good solution to
>>> is the ntp.conf file, which is traditionally installed in /etc/ . If
>>> there is an ntp.keys file,
On 2 March 2015 at 06:10, Harlan Stenn wrote:
>> I'm stuck at one part. Project: Starfighter requires SDL_Image and
>> SDL_Mixer from SDL2 in order to build, so I'm trying to check for them
>> by using AC_CHECK_LIB with functions defined by SDL_Image and
>> SDL_Mixer. These are my checks (you can
On 24 June 2015 at 17:48, Robert Stolarz wrote:
> I'm trying to adapt the library soil2 to work with autoconf.
> http://pastebin.ca/raw/3035774 is what I have so far. My g++ invocation
> reads `g++ -I/usr/include/libdrm -Wall -v -g -O2 -lGLEW -lGLU -lGL -lglfw
> -lm -o giants src/main.o` and `p
On 29 July 2015 at 23:15, Itamar Gal wrote:
> Hey autoconf folks,
>
> I'm following some outdated instructions in an attempt to compile some
> proprietary, closed-source, unsupported, legacy code. Here is what a
> typical shell session looks like:
>
> $ autoreconf -fi
>
> src/Makefile.am:7: error:
On 15 September 2015 at 08:13, Peter Johansson wrote:
> I need to to extract the value of ${datadir} so I can use it something like
>
> val=*extract ${datadir}*
>
> AC_CHECK_FILE([$val], [], [AC_MSG_ERROR([file $val needed])])
Here's what I got with
echo datadir is $datadir
eval datadir=$datadir
On 2 November 2015 at 19:39, Dustin Laurence wrote:
> First problem--configure dies, reporting that "C compiler cannot create
> executables."
Is there anything in config.log that could shed light on the causes of
this failure?
It might be simpler to debug by getting the configure run right from
On 2 November 2015 at 20:41, Gavin Smith wrote:
> These generic installation instructions:
> https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Multiple-Architectures.html
>
> show putting flags directly in CC.
But I should add that using CFLAGS is more
I would like to configure in a subdirectory of a project.
AC_CONFIG_SUBDIRS accumulates its arguments and does them all at the
end, but I'd like it to be done right away.
I searched the archives of the mailing list and found a few
discussions, e.g.
http://lists.gnu.org/archive/html/autoconf/2008-0
On 11 November 2015 at 16:51, Gavin Smith wrote:
> It also needs to be resilient against failure of the subsidiary
> configure script. This happened due to the AC_PROG_CC macro
> discovering that the C compiler didn't exist, or didn't work. This
> compiler was the one that
I think it might be a good idea if AC_PROG_CC_C99 used "c99" in
preference to other command names ("cc") for the name of the C
compiler.
POSIX requires this command to be available:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html#tag_20_11
Why do I make this suggestion? It's d
On 24 March 2016 at 15:05, Russell Wallace wrote:
> I'm writing a C++ program that needs to compile and link with LLVM, and
> trying to figure out how to build it with autotools.
>
> The good news is, llvm-config will supply the relevant compiler and linker
> flags.
Is llvm-config hardcoded into
On 25 March 2016 at 02:25, Russell Wallace wrote:
> How do you do a clean rebuild, i.e. rebuilding all machine-generated files?
> I tried autoconf -i, tried prefixing it with make clean, tried prefixing it
> with make distclean, but configure still had an old timestamp, so I tried
> manually rm co
On 27 May 2016 at 12:56, A.P. Horst wrote:
> I am trying to output an additional header file which should hold a small
> subset if the defines in the regular config.h.
> Currently my simple test setup is set to create test.h:
> AC_CONFIG_HEADERS([config.h test.h])
>
> I have written test.h.in, in
On 30 May 2016 at 07:06, A.P. Horst wrote:
> Thanks for your help.
> Attached is a bare-minimum configure script which demonstrates the problem.
Thanks, I replicated the problem.
I noticed that test.h.in had MS-DOS style line endings (CR LF). When I
changed it to Unix-style (LF), the output file
On 10 June 2016 at 07:10, Kip Warner wrote:
> I'd like to make the fully expanded $sysconfdir shell variable
> available within a file processed via AC_CONFIG_FILES. I am currently
> trying AC_SUBST([SYSCONFDIR], [$sysconfdir]), but it is not fully
> evaluated at ${prefix}/etc which is useless for
On 10 June 2016 at 08:05, Peter Johansson wrote:
> Hi Kip,
>
> I have the following rule in my Makefile.am to generate a C header file.
>
> configmake.h: Makefile
> $(AM_V_GEN)echo '#define BINDIR "$(bindir)"' > $@
>
> You could have a similar rule to generate a file suitable to source into
>
On 20 July 2016 at 22:31, Zack Weinberg wrote:
> I'm also interested in seeing a release in the near future. Is there
> any way people without commit rights (e.g. me) can help?
The obvious answer would be for you to get commit rights. Hopefully
you could agree with the Autoconf maintainers what
On 24 September 2016 at 09:55, Rudra Banerjee wrote:
> But this is giving error:
>
> ./configure: line 4071: syntax error near unexpected token
> `Image::ExifTool,'
> ./configure: line 4071: `AX_PROG_PERL_MODULES( Image::ExifTool, ,)'
> What is going wrong here?
This error shows that the AX_PROG
On 28 December 2016 at 03:30, Anarchean wrote:
> Once in a while:
> % ./configure --prefix="$PREFIX"
I only configure when I need to, for example when the configure script
has changed.
> And then every modification:
> % make
> % make install
> % "$PREFIX/bin/project_name"
I run from the build d
On 24 February 2017 at 16:16, Sascha Manns wrote:
> Hello list,
>
> i'm using that configure.ac: https://github.com/saigkill/PublicanCreato
> rs/blob/master/configure.ac
>
> The autogen.sh works to the end, but configure currently breaks with:
>
> checking for library containing strerror... none r
On Mon, Aug 14, 2017 at 03:31:28PM +0200, Thomas Nyberg wrote:
> Hello,
>
> I just wanted to simplify my previous question. Say I'm starting with
> this file:
>
> # Makefile.am
> ---
> [...]
>
> library_la_SOURCES =
On Wed, May 30, 2018 at 2:25 AM, John Calcote wrote:
> I've tried escaping with backslash, I've tried quoting with single quotes,
> I've tried escaping within double quotes. Nothing works. It seems the
> unquoting functionality will not be tricked into allowing a special
> character to be escaped.
On Wed, Oct 03, 2018 at 12:10:49PM +0200, Sébastien Hinderer wrote:
> Coming to the directory I was talking about, it is currently called
> "target-bindir" and is used to define where the bytecode interpreter,
> ocamlrun, will reside on the target system. This is something the
> compiler running on
On Wed, Oct 03, 2018 at 12:10:49PM +0200, Sébastien Hinderer wrote:
> Many thanks for your openness. Well beyond the particular semantics we
> are trying to achieve, I think one reason for being more permissive
> about the syntax of arguments would be to help people in situation
> similar to mine m
On Fri, Apr 12, 2019 at 10:56:21AM +, Dudziak Krzysztof wrote:
> Hello,
>
> I am not sure if my own understanding of `autoconf` and `automake` purpose
> assignment is correct:
>
> `autoconf` seems to be about configurations
> * to be built on
> * to be built for
> * toolchain to be built on
> * Warnings about obsolete constructs are now on by default.
> They can be turned off with '-Wno-obsolete'.
>
I have tried building the git development version of Texinfo with
the new autoconf, but am deluged with warnings. I get the following
warnings from autoconf:
configure.ac:87: warnin
On Fri, Sep 25, 2020 at 9:07 PM Gavin Smith wrote:
>
> > * Warnings about obsolete constructs are now on by default.
> > They can be turned off with '-Wno-obsolete'.
> >
>
> I have tried building the git development version of Texinfo with
> the new au
%
I am going to try to run autoupdate on the other gnulib m4 files and see
what happens.
commit f077b04f4f694059180a37d1720685b2a1bac544
Author: Gavin Smith
Date: Sun Sep 27 10:20:06 2020 +0100
AS_HELP_STRING
diff --git a/ChangeLog b/ChangeLog
index 8c06171aa..c77f19a68 100644
> -AC_PREREQ([2.60])
> +AC_PREREQ([2.69])
I left this in by mistake from autoupdate; I'd guess it should be left
as 2.60.
> diff --git a/ChangeLog b/ChangeLog
> index 8c06171aa..c77f19a68 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,8 @@
> +2020-09-27 Gavin Smith
> +
> + threadlib, libcrypt: use AS_HELP_MESSAGE instead of AC_HELP_MESSAGE.
> + * m4/threadlib.m4, m4/lib
Because of the upcoming autoconf 2.70 release gives more warnings, I
checked the other files in gnulib in the m4 directory with
autoupdate -v *.m4 2>&1 | tee log
Fortunately, there are not too many issues (on top of the other issues I
already reported). Here are the relevant excerpts from the
On Sun, Sep 27, 2020 at 01:03:03PM -0500, Bob Friesenhahn wrote:
> Today I am trying autoconf-2.69c with GraphicsMagick's configure.ac and am
> only encountering utter failure.
>
> A great many macros (still used to provide backward compatibility) are now
> declared as obsolete. I ran 'autoupdate
On Sun, Sep 27, 2020 at 01:56:06PM -0500, Bob Friesenhahn wrote:
> On Sun, 27 Sep 2020, Gavin Smith wrote:
> >
> > It might help if you could post what the AC_TRY_COMPILE statements were
> > changed into. If I understand correctly the definition in
> > autoconf
> Maybe it is a problem with changequote being used inside an argument to
> a macro. Does it work OK when you remove the changequote lines?
>
> if test "$ac_cv_have_C__func__" != 'yes' ; then
> AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
> [AC_COMPILE_IFELSE([AC_LANG_PR
On Tue, Dec 08, 2020 at 02:14:30PM -0500, Zack Weinberg wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> We are pleased to announce stable release 2.70 of GNU Autoconf.
>
> This release includes eight years of development work since the
> previous release, 2.69. Noteworthy changes
Thanks for writing all of this.
I'm writing from the perspective of a long-term user of the autotools.
A discussion like the one you have started will likely attract many
opinions. Some will be contradictory. However, somebody in the end
will have to decide.
The challenge seems to be to evolve th
On Thu, Jan 21, 2021 at 11:01:34AM -0500, Zack Weinberg wrote:
> Having said that, switching to *anything else* would be a gigantic
> task -- multiple full-time person-years of effort just for the core --
> and would mean either porting or losing all of the third-party macro
> libraries. I don't t
On Mon, Jan 25, 2021 at 02:10:01PM -0800, Paul Eggert wrote:
> On 1/25/21 5:37 AM, Paul Smith wrote:
> > The only thing that would make much of a performance difference, I
> > think, is if we are able to replace lots of shell invocations with
> > built-in make functions like wildcard, if, etc.
>
>
On Mon, Jan 25, 2021 at 10:59 PM Gavin Smith wrote:
> storing the value that should be in CC in the file CC.conf. Does this
> work or does GNU make have other ways of doing this? (It would be
> better if it could be done without communicating via files.) Is there
> any way to se
It seems there are pretty big architectural questions to be
answered. If you paid someone to produce something, you would
get something, but would it be the right thing?
There seems to be the necessity of preserving a linear configuration
script like configure.ac for tests or other code that peop
On Thu, Jan 28, 2021 at 5:44 PM Gavin Smith wrote:
> This has an implication for how existing configure.ac files can be
> parallelised. If it's the first idea, then you are going to put a
> macro somewhere in a configure.ac script that does the parallel bit.
> Otherwise
On Mon, Jan 25, 2021 at 03:15:47PM -0800, Paul Eggert wrote:
> On 1/25/21 2:59 PM, Gavin Smith wrote:
> > Does this
> > work or does GNU make have other ways of doing this? (It would be
> > better if it could be done without communicating via files.) Is there
> >
On Sun, Jan 31, 2021 at 10:14:11PM +, Gavin Smith wrote:
> Another issue is how to record the results of tests from a a Makefile.
> With autoconf, autoconf variables are recorded with AC_CONFIG_FILES
> and AC_CONFIG_HEADERS. Presumably the same would have to be done,
> substi
On Tue, Mar 23, 2021 at 02:06:57PM -0700, Dan Mahoney (Gushi) wrote:
> All,
>
> If you look at a recent version of BIND's named -V (which is not a gnu
> program, but bear with me), you can see a kitchen-sink like line like:
>
> %/usr/local/sbin/named -v
> BIND 9.11.27 (Extended Support Version)
On Wed, Mar 29, 2023 at 09:29:30PM -0500, Jacob Bachmeyer wrote:
> Do we need a direct configure test for "has Perl module"?
> AC_PERL_MODULE([Digest::SHA]) would need to execute `$PERL -e "require
> Digest::SHA"` and consider Digest::SHA available if that returns success.
> Using Perl's -M option
I'm writing about a few things I noticed in the INSTALL file that is
often included at the top level of packages.
A copy of this is kept in the gnulib repository, but as far as I can tell,
the master is kept in autoconf. Please point me in the right direction
if I'm writing to the wrong list.
ht
On Tue, Aug 15, 2023 at 07:01:42PM -0700, Paul Eggert wrote:
> On 2023-08-14 11:01, Gavin Smith wrote:
>
> > It makes no sense to include the Info cross-reference beginning "*note"
> > in a plain text file
>
> Thanks, fixed by installing the attached into
On Fri, Aug 18, 2023 at 10:02:53PM -0500, Paul Eggert wrote:
> > It would make sense to use "INSTALL.ISO"
> > as INSTALL in packages.
>
> In old-fashioned packages perhaps. Nowadays a lot of packages use UTF-8 in
> their source files anyway.
>
> I understand the reluctance to go beyond ASCII. Lon
(link to archived email:
https://lists.gnu.org/archive/html/autoconf/2023-08/msg00011.html).
On Fri, Aug 18, 2023 at 10:02:53PM -0500, Paul Eggert wrote:
> > In the Texinfo package, the script is called "autogen.sh". I doubt that
> > it offers more "fine-grained control" (as stated in the current
On Sat, Sep 28, 2024 at 04:39:52PM -0700, Paul Eggert wrote:
> On 2024-09-28 13:49, Gavin Smith wrote:
> > The text of INSTALL still uses "bootstrap" even though not all packages
> > use this file and there is no reason that they should.
>
> Packages that don'
68 matches
Mail list logo
