On Sun, Aug 9, 2009 at 6:31 AM, santilistas wrote:
> In chapter 3, the diagram showing files for configuring and distributing
> has a line like this:
>
> Makefile.in > Makefile.in
I'm guessing that the first one should be Makefile.am
__
On Sun, Aug 9, 2009 at 7:30 PM, NightStrike wrote:
> On Sun, Aug 9, 2009 at 6:31 AM, santilistas wrote:
>> In chapter 3, the diagram showing files for configuring and distributing
>> has a line like this:
>>
>> Makefile.in > Mak
(autoconf 2.63, automake 1.11)
Why is AS found with AM_PROG_AS instead of AC_PROG_AS? Why is this an
automake thing and not an autoconf thing?
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Currently, the way that I understand it is that automake has versioned
binaries such that autoreconf will call for instance automake-1.11.
This makes it very easy to have multiple versions installed.
Will autoconf ever support this?
___
Autoconf mailin
Sorry, wrong list again :(
-- Forwarded message --
From: NightStrike
Date: Thu, Aug 27, 2009 at 1:48 AM
Subject: Compiler options checking
To: GNU Automake mailing list
What's the preferred autoconf macro to use to check to see if the
compiler supports a certain option
Using autoconf 2.63 and autoscan, my automatically generated
configure.scan has AC_PREREQ as the first macro in the file, and
AC_INIT second. The autoconf manual has this to say about it:
"This macro is the only macro that may be used before AC_INIT, but for
consistency, you are invited not to do
On Sun, Aug 9, 2009 at 1:08 PM, santilistas wrote:
> By the way, is this the correct list to send this remarks?
>
> In section 3.1.2 The Autoconf language, there is the example on Iron
> Maiden and AC_DC.
>
> @example
> echo "Hard rock was here! --[AC_DC]"
> @end example
>
> which results in:
>
>
On Fri, Sep 4, 2009 at 8:22 AM, Eric Blake wrote:
> Yes, indeed. Pushing this (NightStrike, let me know if you'd rather have
> a real name instead of a pseudonym in THANKS):
I prefer anonymity :)
___
Autoconf mailing list
Autoconf@g
How do you test to see if the compiler supports a given option?
Specifically, gcc -municode
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
This:
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 the test is x""yes, as in, with two
double quotes between the x and the yes? Why isn't
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])
That didn't work as expected, though. It just substituted the string literal.
How do I
On Fri, Oct 16, 2009 at 1:22 PM, Ralf Wildenhues wrote:
> 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.i
On Fri, Oct 16, 2009 at 1:32 PM, Ralf Wildenhues wrote:
> * 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
>> &g
On Fri, Oct 16, 2009 at 1:52 PM, NightStrike wrote:
> On Fri, Oct 16, 2009 at 1:32 PM, Ralf Wildenhues
> wrote:
>> * 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_L
On Fri, Oct 16, 2009 at 1:28 PM, Ralf Wildenhues wrote:
> 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
On Tue, Jan 5, 2010 at 2:07 PM, Ralf Wildenhues wrote:
> Automake still needs changes in order for efficient handling of
> fast-changing version strings (as from, e.g., git describe).
What's a fast-changing string?
___
Autoconf mailing list
Autoconf@g
Why doesn't autoscan output the AM_INIT_AUTOMAKE macro into
configure.scan when it detect Makefile.am, but does output
AC_CONFIG_FILES([Makefile]), even when Makefile doesn't exist, but
only Makefile.am does?
___
Autoconf mailing list
Autoconf@gnu.org
h
When I ran autoupdate from 2.65 against my configure.ac that I
manually updated to 2.65, I noticed this change:
-AC_PREREQ([2.65])
+AC_PREREQ(2.65)
Why would autoupdate want to remove the quoting about the version number?
___
Autoconf mailing list
Aut
On Wed, Feb 24, 2010 at 10:43 AM, Eric Blake wrote:
> According to NightStrike on 2/24/2010 8:37 AM:
>> Why doesn't autoscan output the AM_INIT_AUTOMAKE macro into
>> configure.scan when it detect Makefile.am, but does output
>> AC_CONFIG_FILES([Makefile]), even when M
On Wed, Feb 24, 2010 at 10:51 AM, NightStrike wrote:
> Yes, it did not exist:
> [trunk]$ ls
> AUTHORS COPYING.MinGW-w64 DISCLAIMER Makefile.am
> mingw-w64-doc mingw-w64-libraries
> COPYING COPYING.MinGW-w64-runtime DISCLAIMER.PD mingw-w64-crt
> mingw-w64-
On Wed, Feb 24, 2010 at 10:48 AM, NightStrike wrote:
> When I ran autoupdate from 2.65 against my configure.ac that I
> manually updated to 2.65, I noticed this change:
>
> -AC_PREREQ([2.65])
> +AC_PREREQ(2.65)
>
> Why would autoupdate want to remove the quoting about the
I'm sending this to both lists because I don't know which one is
right. I'm trying to conditionally configure and build subdirectories
using Automake conditionals. I'm flipping back and forth between both
manuals, so I'm guessing both apply.
I have a top level configure/makefile that I'm buildin
On Wed, Feb 24, 2010 at 2:23 PM, Ralf Wildenhues wrote:
> The above looks ok to me. Since I cannot, from your description,
> exactly reproduce the code that caused the warning for you, I cannot say
> whether that was a problem.
>
> The code as above does not yet take care of adjusting SUBDIRS (an
On Wed, Feb 24, 2010 at 11:05 AM, Eric Blake wrote:
> According to NightStrike on 2/24/2010 8:48 AM:
>> When I ran autoupdate from 2.65 against my configure.ac that I
>> manually updated to 2.65, I noticed this change:
>>
>> -AC_PREREQ([2.65])
>> +AC_PREREQ(2.65
How about those two minor things I pointed out? :)
Please? :) :)
On Thu, Feb 25, 2010 at 3:56 PM, Eric Blake wrote:
> I'm hoping to release autoconf 2.66 this week. If you are aware of any
> outstanding issues that should be addressed first, please give a heads up.
>
> --
> Eric Blake ebl...@
On Thu, Feb 25, 2010 at 7:18 PM, Eric Blake wrote:
> According to Eric Blake on 2/24/2010 9:05 AM:
>> According to NightStrike on 2/24/2010 8:48 AM:
>>> When I ran autoupdate from 2.65 against my configure.ac that I
>>> manually updated to 2.65, I noticed this chang
How does the variable "AS" get set for the assembler?
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
I ran autoupdate on a configure.ac that yielded the following diff:
- [AC_ERROR([Invalid option: $enable_sdk. Please choose one of ddk,
directx, or all.])])
+ [AC_MSG_ERROR(Invalid option: $enable_sdk. Please choose one of
ddk, directx, or all.)])
The intent of the change is fine, but how aut
On Wed, Mar 3, 2010 at 2:08 PM, NightStrike wrote:
> I ran autoupdate on a configure.ac that yielded the following diff:
>
> - [AC_ERROR([Invalid option: $enable_sdk. Please choose one of ddk,
> directx, or all.])])
> + [AC_MSG_ERROR(Invalid option: $enable_sdk. Please choo
On Wed, Mar 3, 2010 at 2:02 PM, Eric Blake wrote:
> According to NightStrike on 3/3/2010 11:53 AM:
>> How does the variable "AS" get set for the assembler?
>
> Autoconf doesn't mess with $AS. But libtool does
> (libltdl/m4/ltoptions.m4); maybe you should ask
On Thu, Mar 4, 2010 at 6:37 AM, Steffen Dettmer
wrote:
> (OT)
> Do you have some suggestions what tools could help to do such
> nightly builds?
We use buildbot (http://www.buildbot.net/) for the mingw-w64.sf.net project.
___
Autoconf mailing list
Auto
It comes up often that we want to test to see whether a feature of GCC
works. For instance, we want to see if -m64 is a valid gcc option to
know if we should build the 64-bit libraries by default. Other things
include checking for unicode support, and the -municode option. To do
this, we usually
On Sat, Mar 6, 2010 at 12:49 PM, Eric Blake wrote:
> According to NightStrike on 3/6/2010 10:23 AM:
>> It comes up often that we want to test to see whether a feature of GCC
>> works. For instance, we want to see if -m64 is a valid gcc option to
>> know if we should build th
On Wed, Mar 10, 2010 at 3:35 PM, TJ Yang wrote:
> MYARGS=2
> if test $# ne $MYARGS
> then
> echo "Need one argument at least.\n"
> exit 0
> fi
>
> Anyone know there is a similar configure.ac I can learn from ?
Quick and dirty:
if (test) ; then
AS_MSG_ERROR([Invalid options, use --help
On Sun, Mar 7, 2010 at 3:12 AM, Raphael 'kena' Poss
wrote:
>
> Op 6 mrt 2010, om 14:47 heeft Akos Rajna het volgende geschreven:
>
>> Is there any way to use same named sources located in different folders with
>> automake for a C++ project?
>
> This is the autoconf list, not the Automake list.
>
On Sat, May 15, 2010 at 1:52 PM, Natalie Tasman
wrote:
> I'm working on a build system with autotools. I'd like to cross-compile,
> building a mingw/windows executable from linux. So far, my system works
> well with the --host option (and appropriate cross tools installed, from the
> mingw-cross
On Sun, May 16, 2010 at 4:20 AM, Keith Marshall
wrote:
> On Sunday 16 May 2010 04:41:27 NightStrike wrote:
>> > I've considered creating a separate config.ac/Makefile.am for
>> > this one executable, but am hoping to find a simpler solution.
>>
>> There
On Mon, May 17, 2010 at 12:40 PM, Eric Blake wrote:
> On 05/17/2010 08:09 AM, Michael Menegakis wrote:
>> On windows, probably because I had heard windows are very slow in
>> creating new processes unlike UNIX, configuration is mindbogglingly
>> slow.
>>
>> I wonder if there's a way to run it SMP
On Mon, Aug 30, 2010 at 3:09 PM, Ralf Wildenhues wrote:
> Hello Reuben,
>
> * Reuben Hawkins wrote on Mon, Aug 30, 2010 at 06:00:02PM CEST:
>> > Now, if you are still interested in contributing, and maybe in perl
>> > rather than C, then I will send you the details off-list.
>
>> Yes, I'm interest
On Mon, Mar 7, 2011 at 2:10 PM, Ralf Wildenhues wrote:
> Hello, and sorry for any name mangling,
>
> * Eric Blake wrote on Mon, Mar 07, 2011 at 03:44:59PM CET:
>> On 03/07/2011 04:42 AM, СоУВУВ wrote:
>> > "error: ac_nonexistent.h, no such file or directory."
>> > ...
>> > "Compilation terminated.
On Tue, Mar 29, 2011 at 2:35 AM, Ralf Wildenhues wrote:
> Hello Jim,
>
> * Jim Galarowicz wrote on Mon, Mar 28, 2011 at 09:08:02PM CEST:
>> I was wondering if anyone can point me to any information on how to
>> configure from a top-level directory multiple sub-directories with
>> different configu
On Wed, Jul 27, 2011 at 10:22 PM, narke wrote:
>>> On 27 July 2011 14:36, Gary V. Vaughan wrote:
>> because those are in the users' namespace. Instead, Makefile.am should
>> be setting required (but not compiler specific!!) options inside
>> AM_CPPFLAGS/AM_CFLAGS/AM_LDFLAGS/etc. The info manual
On Sat, Jul 30, 2011 at 3:26 PM, Gary V. Vaughan wrote:
> On 31 Jul 2011, at 02:04, NightStrike wrote:
>> On Wed, Jul 27, 2011 at 10:22 PM, narke wrote:
>>>>> On 27 July 2011 14:36, Gary V. Vaughan wrote:
>>>> because those are in the users' namesp
On Wed, Nov 14, 2012 at 11:49 AM, Richard Stallman wrote:
> This problem could be fixed automatically by making the the package
> manager communicate with autoconf, to clear the cache whenever certain
> packages are installed.
Sounds like a fix on the package manager side.
Interestingly, this ca
On Sat, Dec 15, 2012 at 2:18 PM, Paul Eggert wrote:
> On 12/15/2012 03:08 PM, Jeffrey Walton wrote:
>>
>> Is the program designed to remove old core
>> files as part of the autoconf process?
>
>
> No, new cores. 'configure' regularly generates
> programs that dump core, as part of its ordinary
>
Why are link tests not allowed when cross compiling? You don't have
to run the exe to verify that linking worked.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
On Fri, Apr 12, 2013 at 10:26 AM, Eric Blake wrote:
> On 04/12/2013 02:20 PM, NightStrike wrote:
>> Why are link tests not allowed when cross compiling? You don't have
>> to run the exe to verify that linking worked.
>
> What gave you the impression that link tests
On Fri, Apr 12, 2013 at 10:44 AM, Mike Frysinger wrote:
> On Friday 12 April 2013 16:38:29 NightStrike wrote:
>> On Fri, Apr 12, 2013 at 10:26 AM, Eric Blake wrote:
>> > On 04/12/2013 02:20 PM, NightStrike wrote:
>> >> Why are link tests not allowed when cross compi
On Fri, Apr 12, 2013 at 11:15 AM, Eric Blake wrote:
> On 04/12/2013 02:47 PM, NightStrike wrote:
>>>>> What gave you the impression that link tests are not allowed when cross
>>>>> compiling? We use link tests all the time. It is run tests that
>>>>&
AC_SEARCH_LIBS replaced AC_CHECK_LIBS. The latter had an
action-if-found path that did not unilaterally set $LIBS if you
provided a custom action. The former always changes $LIBS, even in
the case of custom actions if found.
This is an issue if you need to check for the existence of a library,
b
Is there a way to tell configure to pipe input into gcc as stdin for
compile tests instead of writing out a temp file and compiling that?
When working on slow, remotely mounted nfs areas, the very large
amount of file i/o latency multiplies its effects considerably.
___
On Tue, Jul 17, 2018 at 11:52 AM, Paul Eggert wrote:
> On 07/16/2018 08:11 PM, NightStrike wrote:
>>
>> Is there a way to tell configure to pipe input into gcc as stdin for
>> compile tests instead of writing out a temp file and compiling that?
>
>
> Not that I know
On 10/26/07, Eric Blake <[EMAIL PROTECTED]> wrote:
> This looks more like an automake question, so I've redirected the mail
> accordingly. Perhaps the answer already lies in the automake manual, in
> creating your own suffix rules:
>
> http://sourceware.org/automake/automake.html#index-Adding-new-
I have a configure.ac file with a line like this:
#AC_CANONICAL_SYSTEM is obsolete
When I run autoupdate, it changes that line to read:
#AC_CANONICAL_TARGET is obsolete
Shouldn't autoupdate ignore comments when scanning for macro names
that need to updating? Or am I doing something wrong?
_
Does autoconf contain a test for checking for whether the compiler
supports SEH, the exception handling method employed by windows?
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
In the manual, it says this:
This macro is the only macro that may be used before AC_INIT, but for
consistency, you are invited not to do so.
Yes, autoscan places AC_PREREQ first. Which is considered "better",
in any sense of the term?
___
Autoconf
If I do this:
AC_CHECK_FUNC(
[chokeme],
[],
[]
)
It will yield shell code that ends in:
if
:
else
fi
Which produces a configure script that dies with:
"syntax error near unexpected token `fi'"
Is this an autoconf bug, or user error on my part?
__
In the autoconf manual, there is a list of a recommended order of operations:
Autoconf requirements
AC_INIT(package, version, bug-report-address)
information on the package
checks for programs
checks for libraries
checks for header files
checks for types
che
On 3/8/08, Andreas Schwab <[EMAIL PROTECTED]> wrote:
> NightStrike <[EMAIL PROTECTED]> writes:
>
> > If I do this:
> >
> > AC_CHECK_FUNC(
> > [chokeme],
> > [],
> > []
> > )
>
> The else part is not empty, it consists of expli
Using AC_CHECK_LIB or AC_SEARCH_LIBS will possibly append -lname to
LIBS where name is the name of the library. If make is nmake on a
windows platform, is this ok? Does nmake require libraries listed in
that variable to be in the form of "name.lib" instead of "-lname"?
Does autoconf support this
On 3/11/08, Brian Dessent <[EMAIL PROTECTED]> wrote:
> NightStrike wrote:
>
> > Using AC_CHECK_LIB or AC_SEARCH_LIBS will possibly append -lname to
> > LIBS where name is the name of the library. If make is nmake on a
> > windows platform, is this ok? Does nma
On Tue, Mar 11, 2008 at 5:35 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > problem because I need to use AR, RANLIB and LD from the Makefiles and I
> can't
> > find AR_FOR_BUILD and co.
>
> Yep. There is no code in Autoconf that sets these *_FOR_BUILD
> variables. If you like you can go
Running autoscan recommands this line in configure.scan:
AC_CHECK_LIB([oad], [main])
I can't seem to find that library, and I can't tell from autoscan.log
what function makes it think that this "liboad" library is needed.
How do I tell?
$ grep autoscan autoscan.log
autoscan: warning: missing AC_
Should AS_CASE
(http://www.gnu.org/software/autoconf/manual/autoconf.html#index-AS_005fCASE-1116)
always be used instead of case/esac inside configure.ac, some local
package m4 script, or AC_DEFUN macros?
___
Autoconf mailing list
Autoconf@gnu.org
http
On 3/13/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Thu, Mar 13, 2008 at 09:20:06PM CET:
> > Should AS_CASE
> > (http://www.gnu.org/software/autoconf/manual/autoconf.html#index-AS_005fCASE-1116)
> > always be used instead of case/esac insi
On 3/13/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Thu, Mar 13, 2008 at 10:07:31PM CET:
> > On 3/13/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > >
> > > AC_INIT
> > > AC_DEFUN([FOO], [echo foo])
> > > AC_D
On 3/13/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Thu, Mar 13, 2008 at 10:35:47PM CET:
> >
> > Ok, now I understand. This is quite an interesting situation. I am
> > guessing that this is why tools like autoscan or autoupdate will use
&g
On 3/13/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Thu, Mar 13, 2008 at 11:52:31PM CET:
> > On 3/13/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > > * NightStrike wrote on Thu, Mar 13, 2008 at 10:35:47PM CET:
> > > >
>
On 3/13/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Fri, Mar 14, 2008 at 12:29:41AM CET:
> > On 3/13/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > > Please let this be productive and name them, so that can be fixed.
> > > T
d be a suitable example for NightStrike to look at.
Thanks :)
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
The way I understand it, automake can't make a new release (1.11)
until some lawyers are satisfied (or some such legal issue). Is
autoconf waiting on this same or similar thing? If not, when is the
next planned release?
___
Autoconf mailing list
Autoc
On 3/23/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Sun, 23 Mar 2008, aaragon wrote:
> >
> > Of course the line above won't do anything, but you get what I mean. Now
> > imagine that instead of 2 libraries, I have 10!!! It's really annoying to
> > have a very big command line with all those
On Tue, Mar 10, 2020, 11:12 AM Zack Weinberg wrote:
> On Mon, Mar 9, 2020 at 5:14 PM Per Bothner wrote:
> > On 3/9/20 1:22 PM, Zack Weinberg wrote:
> > >
> > > - Run the bundled testsuite (plain ‘make check’ only, not ‘make
> > > distcheck’) on the following OS and CPU combinations, all of
On Mon, Mar 23, 2020 at 5:08 PM Zack Weinberg wrote:
> I didn't get any suggestions of additional autoconf-using software
> packages to test. To my mind, that is the biggest remaining hole in
> the plan. Please suggest any software you know of whose autoconf
> usage is particularly complicated
On Tue, Feb 15, 2022 at 6:01 PM Bob Friesenhahn
wrote:
> The people who tell me it is more portable are very interested in
> targeting Microsoft Windows.
Introduce them to mingw-w64.sf.net + msys2 :) I heard good things
about those :P
> The "Makefiles" that Cmake generates are self-referential
75 matches
Mail list logo
