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
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, 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
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
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.
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,
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 ebl...@redhat.com 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 are not allowed when
On Fri, Apr 12, 2013 at 10:44 AM, Mike Frysinger vap...@gentoo.org 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 compiling? You don't have
On Fri, Apr 12, 2013 at 11:15 AM, Eric Blake ebl...@redhat.com 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
require a fallback when cross-compiling
On Sat, Dec 15, 2012 at 2:18 PM, Paul Eggert egg...@cs.ucla.edu 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
On Wed, Nov 14, 2012 at 11:49 AM, Richard Stallman r...@gnu.org 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.
On Wed, Jul 27, 2011 at 10:22 PM, narke narkewo...@gmail.com wrote:
On 27 July 2011 14:36, Gary V. Vaughan g...@vaughan.pe wrote:
because those are in the users' namespace. Instead, Makefile.am should
be setting required (but not compiler specific!!) options inside
On Sat, Jul 30, 2011 at 3:26 PM, Gary V. Vaughan g...@gnu.org wrote:
On 31 Jul 2011, at 02:04, NightStrike wrote:
On Wed, Jul 27, 2011 at 10:22 PM, narke narkewo...@gmail.com wrote:
On 27 July 2011 14:36, Gary V. Vaughan g...@vaughan.pe wrote:
because those are in the users' namespace
On Tue, Mar 29, 2011 at 2:35 AM, Ralf Wildenhues ralf.wildenh...@gmx.de 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
On Mon, Mar 7, 2011 at 2:10 PM, Ralf Wildenhues ralf.wildenh...@gmx.de 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
On Mon, Aug 30, 2010 at 3:09 PM, Ralf Wildenhues ralf.wildenh...@gmx.de 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,
On Mon, May 17, 2010 at 12:40 PM, Eric Blake ebl...@redhat.com 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
On Sun, May 16, 2010 at 4:20 AM, Keith Marshall
keith.d.marsh...@ntlworld.com 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's a way to do this as I
On Sat, May 15, 2010 at 1:52 PM, Natalie Tasman
natalie.tas...@insilicos.com 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
On Wed, Mar 10, 2010 at 3:35 PM, TJ Yang tjyang2...@gmail.com 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,
On Sun, Mar 7, 2010 at 3:12 AM, Raphael 'kena' Poss
autoc...@raphael.poss.name 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
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
On Sat, Mar 6, 2010 at 12:49 PM, Eric Blake e...@byu.net 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 the 64-bit
On Thu, Mar 4, 2010 at 6:37 AM, Steffen Dettmer
steffen.dett...@googlemail.com 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.
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
On Wed, Mar 3, 2010 at 2:08 PM, NightStrike nightstr...@gmail.com 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 choose
On Wed, Mar 3, 2010 at 2:02 PM, Eric Blake ebl...@redhat.com 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 there if you need more help
On Wed, Feb 24, 2010 at 11:05 AM, Eric Blake ebl...@redhat.com 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)
Why would autoupdate want
How about those two minor things I pointed out? :)
Please? :) :)
On Thu, Feb 25, 2010 at 3:56 PM, Eric Blake ebl...@redhat.com 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
On Thu, Feb 25, 2010 at 7:18 PM, Eric Blake ebl...@redhat.com 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 change:
-AC_PREREQ([2.65
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
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
On Wed, Feb 24, 2010 at 10:43 AM, Eric Blake ebl...@redhat.com 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 Makefile doesn't
On Wed, Feb 24, 2010 at 10:51 AM, NightStrike nightstr...@gmail.com 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 nightstr...@gmail.com 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 version
On Wed, Feb 24, 2010 at 2:23 PM, Ralf Wildenhues ralf.wildenh...@gmx.de 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
On Tue, Jan 5, 2010 at 2:07 PM, Ralf Wildenhues ralf.wildenh...@gmx.de 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
This:
xx=yes
AS_VAR_IF([xx],[yes],[echo equal],[echo not equal])
results in this:
xx=yes
if test x$xx = xyes; then
echo equal
else
echo not equal
fi
with autoconf 2.63.
How come the right hand side of the test is xyes, as in, with two
double quotes between the x and the yes? Why isn't it
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
On Fri, Oct 16, 2009 at 1:22 PM, Ralf Wildenhues ralf.wildenh...@gmx.de 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.in. So, I
did
On Fri, Oct 16, 2009 at 1:32 PM, Ralf Wildenhues ralf.wildenh...@gmx.de 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
set x $srcdir/include/sys/*.h
shift
On Fri, Oct 16, 2009 at 1:52 PM, NightStrike nightstr...@gmail.com wrote:
On Fri, Oct 16, 2009 at 1:32 PM, Ralf Wildenhues ralf.wildenh...@gmx.de
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
On Fri, Oct 16, 2009 at 1:28 PM, Ralf Wildenhues ralf.wildenh...@gmx.de 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 = xyes; then
echo equal
else
echo
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
On Fri, Sep 4, 2009 at 8:22 AM, Eric Blakee...@byu.net 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@gnu.org
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
Sorry, wrong list again :(
-- Forwarded message --
From: NightStrike nightstr...@gmail.com
Date: Thu, Aug 27, 2009 at 1:48 AM
Subject: Compiler options checking
To: GNU Automake mailing list autom...@gnu.org
What's the preferred autoconf macro to use to check to see
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
(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
On Sun, Aug 9, 2009 at 7:30 PM, NightStrikenightstr...@gmail.com wrote:
On Sun, Aug 9, 2009 at 6:31 AM, santilistaslis...@gestiong.org wrote:
In chapter 3, the diagram showing files for configuring and distributing
has a line like this:
Makefile.in
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
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
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
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 inside configure.ac, some local
package
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_DEFUN([BAR], [AC_REQUIRE([FOO])
echo bar])
x=zork
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
actual case/if statements instead
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 look how
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
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 nmake require libraries listed in
that variable
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
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 explicit whitespace. When
collecting arguments only unquoted leading whitespace is skipped
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?
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?
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:
69 matches
Mail list logo
