On Thu, Feb 12, 2009 at 7:59 PM, Ivan Levashew
wrote:
> Generally, I'd like build system and compiler to be as humble
> as possible. Don't run tests on my platform, don't look for
> libraries and headers in my /usr directory. If something is not
> specified by means of command line or environment
On Thu, Apr 16, 2009 at 12:16 AM, Bob Friesenhahn
wrote:
> On Wed, 15 Apr 2009, Douglas Held wrote:
>
>> Well, you would just change autoconf so that it fails fast when its
>> configuration is not "well formed"...
>
> How would autoconf know that?
Also, automagic things that work in most cases fa
On Fri, Jun 5, 2009 at 7:34 PM, Ralf Wildenhues wrote:
> Not use -Werror. Seriously, it is impossible to get all configure tests
> [...]
> Just add -Werror at 'make' time if you need to use it.
but this is easy to forget I think...
We have some ARG_ENABLE which then in case does some
CFLAGS="$CFL
Hi all!
On Sat, Jun 6, 2009 at 3:03 AM, Steven G. Johnson wrote:
> As you may or may not know, some of the major supercomputers
> these days (Cray XT3 and IBM BlueGene) require cross-compiling:
> the front-ends run GNU/Linux, but the actual compute nodes run
> some half-baked pseudo-POSIX-ish mini
On Fri, Jun 26, 2009 at 4:54 AM, Ralf Wildenhues wrote:
> if INSTALLDOCS
> MAYBEDOCS = doc
> dist_doc_DATA = README
> else
> docdir =
> endif
> SUBDIRS = src $(MAYBEDOCS)
Can (should) SUBDIRS contain conditionals? Is automake smart to know
that MAYBEDOCS must be entered not for install but
(OT)
Christophe-Marie Duquesne wrote:
> I wonder if there are actually a lot of programmers who used the
> autotools in IDEs and did not came back to classic text editors.
We have a few working with Microsoft Visual Studio and have
automake rules for GNU Make (which IMHO is a kind of functional
p
> more than one text-editor (you've listed two) does
> syntax-highlighting for autoconf scripts, is scriptable, and
> can run subprocesses (emacs and vim aren't IDEs, however -
> though there are _probably_ scripts for each which do specific
> subtasks).
yes, one question is what exactly is an IDE
you would have flag list redundant and it could happen someone will
forget to change one place when adding next flag...
so maybe just call a function?
the withval isn't used? Wouldn't it be --enable-FEATURE then?
oki,
Steffen
dnl surely my example is wrong (quoting, ...) and not portable, I
> That was where I started: I already use
>
> AC_CONFIG_SUBDIRS (zlib compression boost_ext)
> AC_OUTPUT([Makefile])
>
> in the top level configure.ac and
>
> SUBDIRS= zlib compression boost_ext
>
> in Makefile.am
We usually write:
AC_CONFIG_SUBDIRS([p1 p2 p3])
subdi...@subdirs@
is this (more) c
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: is there a way to have
sub-package-specific configure options?
For example, when having packages p1, p2 and p3 and a "p" top level
configure listing
On Fri, Sep 11, 2009 at 11:57 AM, Dan Smithers wrote:
> How can I tell autoconf to run the configure without worrying about it?
AC_CONFIG_SUBDIRS should be sufficient.
> Also, is there a way of setting up cascading projects that don't perform
> all the compiler checks for each sub-project?
is i
On Wed, Sep 16, 2009 at 1:20 AM, Jack Howarth wrote:
> ps Isn't darwin10 the very first hybrid OS which the configure machinary has
> been
> faced with? I am unaware of any other operating systems that ever differed the
> architecture of the kernel and the default code execution/generation of the
Hi,
recent versions check if $CC supports fopen, FILE* and so on. This
breaks environments that don't have / libc.a.
Wouldn't the autoconf way to be to /* undef HAVE_STDIO_H */ but leave
the source code to handle this instead of aborting?
Is it possible to writing something in configure.in to k
Hi,
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 embedded platform. On this platform it might be complicated,
special and non-standard t
Hi,
thanks for your quick reply.
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 versions check if $CC supports fopen, FILE* and so on.
On Thu, Sep 17, 2009 at 8:20 PM, Ralf Wildenhues wrote:
> Hello Steffen,
>
> * Steffen Dettmer wrote on Thu, Sep 17, 2009 at 05:19:46PM CEST:
>> However, configure usually checks if the compiler can create
>> executables. Can (should) this be prevented?
Ohh I missed th
Hi,
thanks for you quick replies.
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?
> > So it is better to have dummy entry code I t
On Fri, Sep 18, 2009 at 7:11 PM, Ralf Wildenhues wrote:
> * Steffen Dettmer wrote on Fri, Sep 18, 2009 at 11:49:20AM CEST:
>>
>> Do I understand correctly that this was a temporary change that
>> had been undone?
>
> Well yes, a regression is a bug in a newer version...
I hope I don't ask a FAQ. If so, an URL would be appreciated.
I've read here that someone could (should?) write
#include
specifying a system header instead of the IMHO correct
#include "config.h"
As far as I know the difference is that in the first version
system directories are searched but
On Tue, Sep 22, 2009 at 3:02 PM, Patrick Welche wrote:
> On Tue, Sep 22, 2009 at 10:49:58AM +0200, Steffen Dettmer wrote:
>> I've read here that someone could (should?) write
>> #include
>> specifying a system header instead of the IMHO correct
>> #include &q
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 directories
> > if it was not found in system directories
>
On Mon, Sep 21, 2009 at 7:37 PM, wrote:
> * Steffen Dettmer wrote on Mon, Sep 21, 2009 at 10:24:26AM CEST:
> > > If you cannot write such a wrapper, then it probably makes
> > > just as much sense to pre-seed a config.site file with
> > > cache variables containin
On Sun, Sep 27, 2009 at 9:43 AM wrote:
> * Steffen Dettmer wrote on Wed, Sep 23, 2009 at 11:26:33AM CEST:
> > On Tue, Sep 22, 2009 at 10:35 PM, wrote:
> > > Not AFAIK. It works because automake adds -I. by default.
> >
> > Yes, unfortunately it adds it.
>
> Y
On Sun, Sep 27, 2009 at 11:45 PM wrote:
> Good Day, dear GNU community :-)
>
>---
> .
> |-- Makefile.am
> |-- base
> | |-- Makefile.am
> | |-- err
> | | |-- err.cpp
> | | `-- err.h
> | |-- io_base.cpp
> | |-- io_base.h
> |-- graph
On Fri, Oct 16, 2009, Rainer Weikusat wrote:
> > If you regenerate your configure file with a newer autoconf,
> > that particular message has been reworded to not sound so
> > scary or severe; we have conceded that some people insist on
> > running with non-triplet-prefixed cross-tools,
>
> Callin
On Thu, Oct 15, 2009 at 10:35 AM, wrote:
> If one runs a configure script, and it needs to show a warning
> for some reason, that could be missed by someone quite easily.
> Is there a way I could
> insert a 10s or so pause, so it becomes more obvious, and they hopefully
> take time to read the war
On Thu, Oct 15, 2009 at 8:29 PM, Ralf Wildenhues wrote:
> configure: WARNING: There have been warnings during this configure run.
>
> when it has come across a AC_MSG_WARNING. WDYT?
(I have difficulties to understand why warnings are needed for
except debug/tracing - for end users, I think, eith
On Fri, Oct 16, 2009 at 11:38 PM, wrote:
> ...handle AC_CONFIG_SUBDIRS...
>
> I could live with "don't"
I would dislike that because people could start to rely on such
an information (in a few years when all configure scripts are
updated) and would miss the recursive warnings (where the feature
w
Hi,
when using recursive configure via AC_CONFIG_SUBDIRS, how to know
(in a sub-configure) where the top directory is?
I mean, something like automakes $(top_srcdir) inside configure.
NB: This is not $ac_top_srcdir which (as far as I understood)
should always point to the directory where the
Hi,
thank you for your great detailed reply!
On Wed, Oct 21, 2009 at 10:08 PM, Ralf Wildenhues wrote:
> * 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 t
(not seen on the list, probably because Carsten is not subscribed, so I forward)
-- Forwarded message --
From: Carsten Heinrici
Date: Thu, Oct 22, 2009 at 9:49 PM
Subject: recursive configure and some $ac_highest_top_srcdir?
To: Ralf Wildenhues
Cc: autoconf@gnu.org, Steffen
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'
> ... dir in $PATH /usr/ucb,ext in '' .exe ...
> cand=$dir/$name$ext
> if test -f "$cand"; then
inte
On Tue, Nov 3, 2009 at 7:23 PM, wrote:
> On Tuesday 03 November 2009 13:58:30 Steffen Dettmer wrote:
>> interesting that this looks for "cl.exe" but not for "CL.EXE". I
>> though uppercase would be correct
>
> On MS-Windows hosts, the file system is
On Tue, Nov 3, 2009 at 11:33 PM, Thomas Dickey wrote:
> On Tue, 3 Nov 2009, Ralf Wildenhues wrote:
>> * Steffen Dettmer wrote on Tue, Nov 03, 2009 at 02:58:30PM CET:
>>> interesting that this looks for "cl.exe" but not for "CL.EXE".
>>
>> You did
On Sat, Nov 21, 2009 at 11:58 PM, Eric Blake wrote:
> It looks like a carriage return may be interfering with the resulting
> message. Could this be a case of using text mode line endings, instead of
> binary mode? On cygwin, autoconf is only supported on binary mounts.
Ohh really? Is this a ne
AGE-
> Hash: SHA1
>
> According to Steffen Dettmer on 11/23/2009 2:11 PM:
>> On Sat, Nov 21, 2009 at 11:58 PM, Eric Blake wrote:
>>> It looks like a carriage return may be interfering with the resulting
>>> message. Could this be a case of using text mode line endi
* Glus Xof wrote on Tue, Dec 15, 2009 at 18:59 +0100:
> > I would make no changes to configure.ac or Makefile.am,
> > as you're looking in the wrong place. The type of questions
> > you're asking are more appropriate for the package
> > management system, and you should be making changes to
> > yo
On Fri, Feb 5, 2010 at 7:28 PM, wrote:
> On Fri, 5 Feb 2010, j.wuttke wrote:
>
>> A user of my software package reported that compilation on
>> a virtual Linux machine running on his Mac failed because
>> '::malloc' was not declared.
>>
>> We then found that AC_FUNC_MALLOC actually produced a 'no'
Hi,
I assume a non-gcc cross compiler should ideally be installed as
cpu-manufacturer-cc, lets say arm-steffens-cc. But I was told
that for arm-steffens platform then configure searches
arm-steffens-gcc, arm-gcc, gcc, arm-steffens-cc - but because gcc
usually exists, too, it will never use arm-ste
Hi,
how to handle new subdirectories?
1) new automake but no new autoconf directories:
For new subdirectories with new Makefile.am autoconf/automake
fails because Makefile.in seems not to be created automatically,
so we usually add in configure.in a call to a macro similar like
that:
--
Hi,
in configure.in I have:
AC_CHECK_FUNCS(printf)
together with some
--->8===
AC_DEFUN([IC_ENABLE_ERRORS],[
AC_ARG_ENABLE(errors,
[ --enable-errors[=ARG] Enable error mode
(warnings are errors) [ARG=no]],
Hi,
thanks again for your quick and helpful reply.
On Wed, Mar 3, 2010 at 7:33 AM, Ralf Wildenhues wrote:
> * Steffen Dettmer wrote on Tue, Mar 02, 2010 at 04:25:50PM CET:
>> For new subdirectories with new Makefile.am autoconf/automake
>> fails because Makefile.in seems no
Hi,
thanks for your quick reply.
On Wed, Mar 3, 2010 at 1:54 PM, Eric Blake wrote:
> According to Steffen Dettmer on 3/3/2010 4:31 AM:
> > I have a new dir with dir/configure.in and added it to
> > ./configure.in's AC_CONFIG_SUBDIRS([dir]).
>
> You may want to conside
On Wed, Mar 3, 2010 at 1:47 PM, Eric Blake wrote:
> According to Ralf Corsepius on 3/3/2010 4:04 AM:
>> On 03/03/2010 11:52 AM, Steffen Dettmer wrote:
>>> Hi,
>>>
>>> in configure.in I have:
>>>
>>> AC_CHECK_FUNCS(printf)
>
> C89
On Wed, Mar 3, 2010 at 2:44 PM, Eric Blake wrote:
> According to Steffen Dettmer on 3/3/2010 6:33 AM:
> > Do I understand correctly that it is generally adviced to not use
> > the option -Werror?
>
> Not quite. The advice is to not mix -Werror and configure.
ahh ok, this
On Wed, Mar 3, 2010 at 3:00 PM, Ralf Corsepius wrote:
> Another aspect is -Wall and -Werror are moving (and
> architecture dependent) targets. I.e. the number of warnings
> GCC will issue changes over time, triggering different kind of
> warnings.
Yes, new compiler versions or includes (SDK updat
On Wed, Mar 3, 2010 at 3:59 PM, Eric Blake wrote:
>> I'm afraid again I just fail to see the obvious and it is very
>> easy to do?
>
> Yes. Here's how m4 does it. It uses the gl_WARN_ADD macro from the
> gnulib module manywarnings; but if you choose not to use gnulib, it is a
> simple enough mac
On Wed, Mar 3, 2010 at 8:41 PM, Russ Allbery wrote:
> WARNINGS =
> warnings:
>$(MAKE) V=0 CFLAGS='$(WARNINGS)'
>$(MAKE) V=0 CFLAGS='$(WARNINGS)' $(check_PROGRAMS)
yes, also a nice idea :)
> The coding style standard then requires that all code compile
> with make warnings before
Hi *,
hey guys, thanks so much for all the helpful replies and the patience with me.
You just rock, great, thank you.
have a good night (or day :)) everyone!
oki,
Steffen
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinf
(OT)
On Thu, Mar 4, 2010 at 12:42 AM, Russ Allbery wrote:
> Steffen Dettmer writes:
>
>> I would guess the users that forget to fix warnings are the same
>> that forget to run `make warning' :)
>
> Well, you also have the same problem with developers who don'
On Thu, Mar 4, 2010 at 12:55 AM, Eric Blake wrote:
> even a few shell commands
Yes, for appending a line, echo seems suited :)
> find . -name Makefile.am | xargs sed -i -e "$script"
Ohh, I didn't knew that recent sed's have -i (I assume it is
inplace-edit link perl -i). cool.
(however, accordi
On Thu, Mar 4, 2010 at 12:45 AM, Eric Blake wrote:
>> - Alternatively, by accident, ts there some way to tell configure
>> something like: right just before writing config.status, set
>> `CFLAGS=$CFLAGS\ $WERROR_CFLAGS' or so?
>> As Peter suggests?
>
> Perhaps; AC_CONFIG_COMMANDS_PRE probabl
Hi,
I'm trying to understand the motivation for renaming configure.in
to configure.ac. If I remember correctly it was related to the
fact that ./config.status or whoever else processes .in files.
I goggled but was unable to find it.
If this is the motivation and no `effects' depend on the file
n
On Mon, Mar 8, 2010 at 12:29 PM, Ralf Corsepius wrote:
> * On 03/08/2010 12:12 PM, Steffen Dettmer wrote:
> > I'm trying to understand the motivation for renaming configure.in
> > to configure.ac. If I remember correctly it was related to the
> > fact that ./con
On Mon, Mar 8, Bob Friesenhahn wrote:
> It is also interesting to note that it is usually ok for the
> content of the header file to be parsed any number of times.
> The only exception might be with some weird macro expansion
> (but that would be a bug).
>
> The conditional inclusion of content is
On Mon, Mar 8, 2010, John Calcote wrote:
> internal.h:
> #ifdef HAVE_CONFIG_H
> # ifndef CONFIG_H_INCLUDED
> #include "config.h"
> #define CONFIG_H_INCLUDED
> # endif
> #endif
If, as it is needed to be, config.h is always one and the same file
and contains #defines only, no such guard i
On Mon, Mar 8, 2010 at 2:21 PM, Eric Blake wrote:
> "Steffen Dettmer" wrote:
> > ok, let me rephrase my question:
> > What was the motivation to change the name of the main file to be
> > processfrom by autoconf to .ac?
>
> Because *.in designates a file that
On Mon, Mar 8, 2010 at 6:27 PM, Peter Breitenlohner wrote:
> > > Everything else is philosophy/ideology.
I thought concluding content from file name was MS-DOS style
(because MS-DOS had no /bin/file and big use of pipes), but it
seems several un*x tools also per default assume content based on
fi
Hi,
to prepare a TCP socket, usually someone calls something like:
int sockfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
however, on older linux versions, for example 2.2.16, this
returns a socket on which bind(2) will fail with `address already
in use'. Here, the following works:
int s
Hi,
we have a generic .m4 file and it has package-specific options in such a way:
AC_ARG_ENABLE(AC_PACKAGE_NAME[-logging],
[ --enable-]AC_PACKAGE_NAME[-logging[=ARG] Enable logging
for ]AC_PACKAGE_NAME[ [ARG=yes]],
is this the good / right / correct way to do that or are
* Eric Blake wrote on Tue, Apr 13, 2010 at 13:52 -0600:
> This should work, but you may want to also use AS_HELP_STRING for better
Hi,
thanks so much for your instant reply :)
I think such an approach could be good for many options, also
--enable-debug etc,
by this options can be set package-wis
* On Mon, May 17, 2010 at 9:44 PM, wrote:
> * Am Montag, den 17.05.2010, 10:18 -0600 schrieb Eric Blake:
> > What you are attempting doesn't make much sense to me yet.
> > The whole point of i18n is that the translation files can be
> > maintained independently of the executable, and that a person
* Ralph Blach wrote on Thu, May 20, 2010 at 16:57 -0400:
> Ralf Wildenhues wrote:
> >* Ralph Blach wrote on Thu, May 20, 2010 at 10:27:59PM CEST:
> >
> >>AC_DEFUN([AC_CHECK_FUNC_PROTO],
> >> [AC_CACHE_CHECK(for $1 function prototype in $2, ac_cv_have_$1_proto,
> >> AC_EGREP_HEADER($1
On Mon, Aug 2, 2010 at 7:17 AM, Ralf Wildenhues wrote:
> * Thomas Petazzoni wrote on Mon, Aug 02, 2010 at 03:33:53AM CEST:
>> So the ability of sharing the cache between execution of
>> different configure scripts is a documented feature. Is it just that in
>> reality it doesn't work that well ?
>
On Thu, Aug 26, 2010 at 4:25 AM, Reuben Hawkins wrote:
> I'm porting a large Windows toolkit to Linux, OSX, etc. Is there a
> tool which will walk my directory structure outputting Makefile.am in
> each directory where needed?
I'd recommend to consider alternatives to the `one Makefile.am per
di
On Thu, Sep 2, 2010 at 9:18 PM, Peter Rosin wrote:
> (background: I want to have Libtool on Cygwin drive MSVC, and
> Cygwin creates soft links that MSVC does not understand. The
> Libtool testsuite invokes autoconf followed by configure several
> times when it runs).
couldn't this break dependcie
On Fri, Sep 3, 2010 at 8:18 AM, Peter Rosin wrote:
> Den 2010-09-02 21:50 skrev Steffen Dettmer:
>> On Thu, Sep 2, 2010 at 9:18 PM, Peter Rosin wrote:
[cp instead of ln -s]
>>
>> couldn't this break dependcies?
>
> I'm using MSVC to cross-compile from the Cyg
On Thu, Sep 2, 2010, Ralf Wildenhues wrote:
> Well, we /should/ fix Autoconf to allow overriding, and at that
> point, you should be able to override globally with export
> LN_S=...
Is it a good idea to use this to override symlinking to something
different?
Isn't this close to `AR=winzip GREP=a
On Fri, Sep 3, 2010 at 12:24 PM, Peter Rosin wrote:
> Den 2010-09-03 11:47 skrev Steffen Dettmer:
> Sorry, but there's just no way to make MSVC invoke cygpath when
> it sees
>
> #include "ltdl.h"
>
> in some .c file and ltdl.h is a symlink.
ohh sure... I mi
On Sun, Sep 12, 2010 at 7:09 PM, wrote:
> On Sun, Sep 12, 2010 at 6:19 PM, wrote:
>> Well, distcheck (which comes from Automake) really aims to be a "come
>> on, let me ensure this package is good in all kinds of ways" target,
>> so it also tries out installcheck. This makes sense, too, because
On Mon, Oct 18, 2010 at 9:29 PM, Ed Hartnett wrote:
> It would be great if, each time netCDF were built, we would get
> an email from the build system, telling us things like what
> configure options were used, what compilers were used, and what
> the platform was.
[...]
ARG!
> Is there
On Thu, Jan 13, 2011 at 8:18 PM, Ralf Wildenhues wrote:
> * David Bruce wrote on Thu, Jan 13, 2011 at 04:16:34PM CET:
>> > DISTCLEANFILES = _configs.sed esio/esio-config.h
> distclean-local: distclean-ax-prefix-config-h
>
> Using the -local targets is the recommended way to extend targets,
Hope
In short:
I think, no cache loading from manual explicite configure run
(but for sub-packages and make-triggered), keeping it as it is.
By this, if in doubt, by re-running all build tools, chances are
best to get a correct result. Performance tuning for the price of
correctness isn't always a good
Hi,
for a project I needed to select C++98. When using g++, this is done
by adding compiler flag "-std=c++98". I liked to have a compiler check
whether this option works.
A web search revealed that this seems not to be intended for maximum
portability; language should not be limited. A similar th
Hi,
we use autoconf (and automake) with self-written configure.in/ac
scripts since a long time but probably wrong in several aspects.
I hope this is the right place to ask, otherwise please tell!
If I understood correctly, passing --host in general enables
cross compiling.
My question in shor
Hi,
when in configure some test construction found lets say
LDFLAGS="$LDFLAGS -Wl,--script=${srcdir}/lib/link.txt"
for automake in Makefile this should become
LDFLAGS="$LDFLAGS -Wl,--script=$(top_srcdir)/lib/link.txt"
to work in subdirectories also. Inside configure, $(top_srcdir) of
cours
* Harlan Stenn wrote on Tue, Sep 02, 2008 at 18:12 +:
> > Peter O'Gorman wrote:
> >
> > > Josef noted that he did not want this to change. I'm inclined to agree
> > > with him, people who are cross-compiling may not have all of the `tools'
> > > available as triplet-prefixed-name, but are like
* Bob Rossi wrote on Tue, Sep 02, 2008 at 14:35 -0400:
> I don't know anything about what you guys are talking about, but, i know
> that symlinks don't work well on windows. Do you have a workaround for
> msys/windows, or systems that don't handle symlinks well?
maybe simply using copy (works for
78 matches
Mail list logo
