Julian Cummings schrieb:
Attached is a proposed patch for the autoconf macro ax_enable_builddir.m4.
The patch universally replaces host with build and HOST with BUILD.
The rationale is that typically the user wishes to segregate builds based
upon the BUILD target rather than the configuration
Peter Simons schrieb:
Guido Draheim writes:
Peter Simons writes:
Hi Julian,
thank you for taking the time to update the macro. Your patch
certainly feels reasonable to me, so I applied it to the macro:
http://autoconf-archive.cryp.to/ax_enable_builddir.html
I
Eric Lemings schrieb:
Hi,
I want to write an Autoconf macro that checks for overloaded functions
in C++ (assuming of course all basic C++ configuration checks have been
done). For example, does the C++ compiler support function calls to
abs() in math.h or cmath for all integer types
Reminder:
- http://ac-archive.sourceforge.net/guidod/ax_prefix_config_h.html
The macro creates a package config.h that can be installed.
It avoids to create a special ace-config.h manually.
Point the ACE developers to that as installing config.h is plain wrong.
And, use it yourself thereby
Dirk schrieb:
Guido Draheim wrote:
https://sourceforge.net/forum/forum.php?forum_id=665363
As of 2007-02-08, SourceForge.net Compile Farm service
has been officially discontinued.
We feel that our resources are best used at this time
in improving other parts of our existing SourceForge.net
Thomas Dickey schrieb:
On Thu, 15 Feb 2007, Dalibor Topic wrote:
HP's test drive covers a bunch of platforms. For the rest: qemu,
vmware, aranym, hercules, gxemul, or (least desirable, imho) real
hardware.
It's less than it was (about half the platforms went away last fall).
However it
It is great that aclocal/autoconf can now m4_include multiple
files from a local m4/-subdirectory. Yet, I was missing a tool
to populate it. A while back I just modified the standard
aclocal to do that - i.e. instead of --ouput=FILE using an
--output-dir=DIR. However, as far as I can see, the
Peter Simon's mail does contain a lot of allegations - I will
refrain to clarify in the same length. I hope that quite some
people on the Autoconf list know me well enough to assume that
there had never been bad intentions whatsoever on my side.
Peter has been contacting me on Sunday to ask about
sorry for getting offtopic - I guess autoconf mailinglist is the
place where most people live that care about maximum
platform portability on the base of the least common den...
what:
mksite.sh is yet another html doc formatter,
ah, the 1500th microtool on freshmeat.
why:
it has only one
Patrick Guio wrote:
Dear all,
This is not really a bug but I wonder if you have any remedy to the
following problem. If you use autoconf/automake for several packages
which interact with each other and for each package you generate a
^^
configuration file config.h you migh
I did try this intially as well, converting the config.h to a
derived xconfig.h with all defines being #ifndef/def. It
did turn out to be problematic with some packages
having parts of their public header defines enabled/disabled
depending on configure-time values packed onto
xconfig.h - including
Bob Friesenhahn wrote:
On Sun, 21 Dec 2003, Jeff Sheinberg wrote:
Paul Eggert writes:
Florian Weimer [EMAIL PROTECTED] writes:
I'm writing a library that will require large-file support on 32-bit GNU
^^
platforms
Florian Weimer wrote:
Bob Friesenhahn wrote:
I recommend defining your own equivalents to off_t ino_t (if needed)
which are *always* 64 bits wide. Only your library implementation
uses the system off_t ino_t definitions and they are not used in
your public library headers. This way your
Bob Friesenhahn wrote:
On Sun, 21 Dec 2003, Guido Draheim wrote:
My configure script needs to have access to the values that
AC_SYS_LARGEFILE sets since including config.h is not sufficient for
all applications. Sometimes the options *must* be specified on the
compiler command line to work
Bob Friesenhahn wrote:
On Sun, 21 Dec 2003, Guido Draheim wrote:
Well, that doesn't work that well if you are writing a C++ POSIX binding
and don't want to duplicate those data structures. But I see you point.
Maybe I should make the affected functions artificially templated, this
would get
Florian Weimer wrote:
I'm writing a library that will require large-file support on 32-bit GNU
platforms (so that off_t and ino_t are 64 bits wide, otherwise data
structure layout would change). What is the canonical way to enforce
this?
I guess it's not a good idea to force applications to
Peter Eisentraut wrote:
Fredrik Tolf writes:
How do I get the sysconfdir into a cpp macro if I use automake as
well? Should I do it through a config header, or should I do it via
some automake contraption? Should I just add it to CPPFLAGS? Please
tell me.
The Autoconf manual tells the tale:
Ralf Wildenhues wrote:
Hi there,
I have a library package which uses AC_CONFIG_HEADERS to create a
non-installed generic config.h header as well as an installed header
providing (very few) configuration options for the library, with the
#define's suitably named (e.g. _LIBFOO_FEATURE_BAZ).
My
Ralf Wildenhues wrote:
* Guido Draheim wrote on Mon, Dec 01, 2003 at 09:25:39AM CET:
Ralf Wildenhues wrote:
*snip*
Now current CVS autoheader (2.59a) gives me
|autoheader: warning: missing template: _LIBFOO_FEATURE_BAZ
|autoheader: Use AC_DEFINE([_LIBFOO_FEATURE_BAZ], [], [Description
I know the m4 macro processing to be quite sophisticated but what would
be your idea about the _best_ way to allow dualmode macros? Something
like ifelse(autoconf, 2.13, ac_path_prog(x), ac_path_tool(x)), or some
ifdef variant, or whatever ... what could be the _recommendend_ style?
cheers,
--
[EMAIL PROTECTED] wrote:
This is somewhat off topic so feel free to respond privately.
We want to add LFS to our package. I currently do not know what this
involves:
I know there's the defines:
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
but I'm not sure how portable that is. Our package
Bob Friesenhahn wrote:
On Mon, 10 Nov 2003, Guido Draheim wrote:
Please have a look at my LFS propaganda site at
http://ac-archive.sf.net/largefile
and feel free to mail me anything that's not clear
after reading it up. My zziplib project has even
gone to the next step of being a dualmode
Bob Friesenhahn wrote:
On Mon, 10 Nov 2003, Guido Draheim wrote:
That may be difficult to accomplish. I am not aware that Windows
stdio and other high-level Windows I/O interfaces support large
files since the APIs are 32 bit. You need to use _read, _write,
_lseeki64, _telli64 to support
Bob Friesenhahn wrote:
On Thu, 30 Oct 2003, Larry Doolittle wrote:
would be responsible for writing the bit of Tcl code required to
interface to the target.
I have never used DejaGNU. I think a lot of embedded development
systems can download executables and run them, one way or another.
You
Hi Larry,
I am into the crosscompiling thing a lot, and in fact
the most common targets are embedded platforms which
can not bear a full fledged development environment.
Those could not benefit quite from your proposal
unless they are big enough to run a compiler which
in turn has access to a
Paul Eggert wrote:
Larry Doolittle [EMAIL PROTECTED] writes:
Comments? If I developed, tested, and submitted a patch,
would anybody look at it?
Yay! I would! (But it'd be after 2.58 of course.)
Here are some more detailed thoughts:
1. Add a new flag, like CROSS_RUN_SCRIPT, that
Kevin Ryde wrote:
Balint Joo [EMAIL PROTECTED] writes:
In my case the answer is that I am trying to compile a parallel
program, which needs a special compiler (mpcc). However in order
to run the output of mpcc, I need to be in a batch queue. Outwith
the batch queue I cannot run executables
Balint Joo wrote:
Dear All,
I have a question which is almost 'theological'.
Consider a case, where your --host system (on which the code will run)
and the --build system (where you compile) have the same canonical
name, but yet you still don't want AC_PROG_CC to produce a test
executable
Frank A. Uepping wrote:
Each directory containing source files should have a ChangeLog.
Should changes to the `GNU build system' source files (configure.ac,
Makefile.am) also be recorded into the ChangeLog?
Yes and No. Each directory and each change - that would be much too much,
and people
Larry Siden wrote:
I forgot to send this message to the whole group last time. Please read
and see if you can help me. Thanks. -ls
Subject:
Re: pkg-config and autoconf
From:
lsiden [EMAIL PROTECTED]
Date:
09 Aug 2003
Thomas E. Dickey wrote:
On Tue, 12 Aug 2003, Guido Draheim wrote:
of another file. In all other cases, I'm quite fine... what features
are overdue by your records, Thomas?
I suppose you could look at the cvs version and answer your own question.
I recall seeing a half-dozen serious bugs
Thomas Dickey wrote:
On Tue, Aug 12, 2003 at 11:24:35AM +0200, Guido Draheim wrote:
Oh well, I know the situation all too well - the distro makers
yes, what a shame that the current autoconf developers chose to not
make their changes compatible, so one could easily slide an old
script
Braden McDaniel wrote:
Quoting Larry Siden [EMAIL PROTECTED]:
How can I get autoconf to automatically find header files that are not
part of the standard include path, but for which *.pc files exist?
You don't need to do that; if the pkg-config metafile is on the system, the
assumption is
Larry Siden wrote:
I want to check for non-standard headers, such as, pango/pango.h,
glib.h, and others. AC_CHECK_HEADER seems to work only for standard
headers, i.e. headers that can be found in the standard include path.
How can I augment the include path for other headers?
The same way as it
Braden McDaniel wrote:
On Fri, 2003-08-01 at 23:44, Harlan Stenn wrote:
It's not that hard to get rid of a flag.
nCFLAGS=
for i in $CFLAGS
do
case $i in
-g) ;;
*) nCFLAGS=$nCFLAGS $i ;;
esac
done
CFLAGS=nCFLAGS
That will also purge -g if it was added explicitly by the user.
Frank A. Uepping wrote:
On Friday 01 August 2003 23:25, Guido Draheim wrote:
Frank A. Uepping wrote:
Unfortuantely AC_PROG_CXX includes the `-g' option in CXXFLAGS,
with what I am not happy with.
How can I get rid of the `-g' flag in a way that doesn't *clobber* a user
supplied CXXFLAGS
Frank A. Uepping wrote:
Unfortuantely AC_PROG_CXX includes the `-g' option in CXXFLAGS,
with what I am not happy with.
How can I get rid of the `-g' flag in a way that doesn't *clobber* a user
supplied CXXFLAGS?
(However, I assume resetting CXXFLAGS entirely is not wise, isn't it?)
Is there any
Frank A. Uepping wrote:
Hi,
assume someone has finished a software project and wants to distribute it
with autoconf. Currently the software compiles and runs on the platform of
the developer; though the developer is interested to get the software run on
other platforms as well, if there is a
I did configure with the --prefix switch (on the plain 0702g version)
and something seems to be wrong:
--
(configure of gai went ok)
cd example configure '--prefix=/usr/local/Libs/gai'
configure: error: invalid variable name: '--prefix
configure: configure in example/ done
Hi Jonas,
I had a
Simon Waters schrieb:
The trouble with staying upto date is everything complains about old stuff.
After upgrading autoconf tools got some complaints from configure that
AM_INSTALL_PROG was out of date.
This was in ac_create_stdint.h, being keen I pulled AX_CREATE_STDINT_H
from sourceforge, but
I had that idea for a long time but I knew that it would require
some iterations of testing before it works smoothly. Finally, there
was enough time lately to give it a try and here it is - a new macro.
* what is it?
Per default, autoconf/automake builds are done within the source
directory. The
Guido Draheim schrieb:
* benefits
there are a number of benefits to use a subdir build, many of which
were covered in earlier threads on the autotools mailinglists. To
hilight some:
- multi user access to the same source repository
- multi arch builds in the same repo in a networked /home
Paul Eggert schrieb:
Guido Draheim [EMAIL PROTECTED] writes:
I am using
AC_SYS_LARGEFILE
AC_CHECK_FUNCS(ftello fseeko)
Use AC_FUNC_FSEEKO rather than AC_CHECK_FUNCS(fseeko).
That should work around your problems.
Thanks. However, that macro still calls the glibc
behavior a bug, which I
Guido Draheim schrieb:
Paul Eggert schrieb:
Guido Draheim [EMAIL PROTECTED] writes:
I am using
AC_SYS_LARGEFILE
AC_CHECK_FUNCS(ftello fseeko)
Use AC_FUNC_FSEEKO rather than AC_CHECK_FUNCS(fseeko).
That should work around your problems.
Thanks. However, that macro still calls the glibc
Petr Vandrovec schrieb:
On 17 Mar 03 at 11:33, Guido Draheim wrote:
Personally, I think it would be the best to simply
add a global change in features.h
What about reading LFS standard: if _LARGEFILE_SOURCE is not
defined, neither fseeko nor fseeko64 do exist. Take it up
with standard
Petr Vandrovec schrieb:
On 17 Mar 03 at 12:02, Guido Draheim wrote:
Petr Vandrovec schrieb:
On 17 Mar 03 at 11:33, Guido Draheim wrote:
Personally, I think it would be the best to simply
add a global change in features.h
What about reading LFS standard: if _LARGEFILE_SOURCE is not
defined
I am using
AC_SYS_LARGEFILE
AC_CHECK_FUNCS(ftello fseeko)
Later in the source files, I have some
#include config.h
#include stdio.h
#ifdef HAVE_FTELLO
#define _ftell ftello
#else
#define _ftell ftell
#endif
When configuring, I see...
checking for unistd.h... (cached) yes
checking for off_t...
Bob Lockie schrieb:
They seem to do the same thing.
Why should I use one macro over the other?
configure --help
installation directories:
...
Program names:
...
System types:
...
Optional Features:
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
...
Optional
Bill Wendling schrieb:
Hi all,
I want to produce a help string like this:
--with-foo[=DIR]Use the foo package
(note the []s around the =DIR bit). When I use the option like this:
AC_ARG_WITH([foo],
[AC_HELP_STRING([--with-foo[=DIR]],
Roger Leigh schrieb:
Bill Wendling [EMAIL PROTECTED] writes:
I want to produce a help string like this:
--with-foo[=DIR]Use the foo package
(note the []s around the =DIR bit). When I use the option like this:
AC_ARG_WITH([foo],
[AC_HELP_STRING([--with-foo[=DIR]],
Peter Simons schrieb:
(5) We leave everything as it is, and the GNU archive starts
downloading the contents from the SourceForge archive as well. (I
list this option for the sake of completeness. I do not want to
include submissions into the GNU archive unless they come from
The tex-like settings for the classic-format happen to be sometimes
a bit long - the synopsis can be quite long and sometimes we want
to have even some more of them (as we know from an earlier thread).
I would like to see abbreviations of the extra markup of macros in
the ac-archive classic
Peter Simons schrieb:
would make you believe that I do not want to include submissions
unless they come from the author of the macro. Downloading the macros
from a third-party site is not an option. Not to mention the fact that
two archives cross-updating each other is a maintenance nightmare.
Peter Simons schrieb:
I would like to see the two archives merge as much as any of us, and I
realize that we will never see that happening unless we are able to
compromise. I requested help multiple times, and you have offered help
multiple times. So obviously we have a match.
The first and
Peter Simons schrieb:
Guido Draheim writes:
- A short description of the macro (summary) is visible on the
index page.
I did try that lately too - but dumped it as it did clutter the
index page with information not really helpful.
There is no need to force the summary onto the index
Peter Simons schrieb:
Guido Draheim writes:
I am not sure however if it is best to use br instead of a proper
list that gets visuallized with as a the list combined with br
between them.
IMHO the only viable alternative would be to use an abstract
description of macro parameters, which
Peter Simons schrieb:
Let me summarize the statements you made in your e-mail:
Oh my... no phone call then.
Let me inject a short paragraph to the casual reader: flame wars
are nothing atypical in the opensource world, in fact it is thought
of being quite helpful as to clean up things and it
Peter Simons schrieb:
I quoted, among others, the following CVS IDs:
$Id: ac_config_libconfig_in.m4,v 1.2 2002/04/19 12:03:00 simons Exp $
$Id: ac_config_libconfig_in.m4,v 1.4 2002/09/12 22:11:52 guidod Exp $
$Id: ac_config_pkgconfig_in.m4,v 1.2 2002/05/06 11:47:30 simons Exp
Peter Simons schrieb:
Another statement that we can actually verify. The complete list of
macros which are found on the SourceForge branch and _not_ in the
GNU archive is:
ac_func_vsnprintf.m4
ac_lib_readline.m4
ac_prog_cc_warnings.m4
ac_prog_fig2dev.m4
All of these
Guido Draheim schrieb:
- is no such tool in the gnu branch, so that it can be guilty
+ is no such tool in the gnu branch, so that it can not be guilty
(I hope that was obvious tho...)
to contribute ...
|
| then please don't hesitate a second! Just send the m4 source to
| Guido Draheim [EMAIL PROTECTED] via electronic mail. [...] Note that
| the two ac-archive repositories (sourceforge and savannah) are
| constantly kept in sync [...].
The two archives are NOT kept in sync. You
Peter Simons schrieb:
Guido Draheim writes:
I hand out cvs access to the sfnet branch quite freely [...].
What, according to
http://sourceforge.net/project/memberlist.php?group_id=32081
accounts for the two developers:
Bruce Korb
Guido Draheim
The ones, who's macros the GNU
Peter Simons schrieb:
Anyway, this is leading nowhere. I quit this thread and return to my
well-established ignoring the users-routine.
Hopefully not - we should really get this matter settled.
There is no point in doing strange politics and have
autoconf users wonder what that is about with
Peter Simons schrieb:
Compared to the old mark-up format, this has the following significant
advantages:
- A short description of the macro (summary) is visible on the index
page.
I did try that lately too - but dumped it as it did clutter the index
page with information not really
Martijn Ras schrieb:
Heya Folks,
Reading this and other mailing lists of configuration building tools
helped me automating the build process of a number of projects i
'm maintaining. However, i'm having difficulty solving the last step and
hope you may help me out.
I used to duplicate my
Paul Eggert schrieb:
Date: Sat, 11 Jan 2003 20:05:30 +0100
From: Guido Draheim [EMAIL PROTECTED]
why not let those scripts check for spurious instances of
fopen/lseek and friends and warn at them - so that libraries and
modules are compiled 64bit always (using the alternate symbols
fopen64
Paul Eggert schrieb:
Date: Mon, 06 Jan 2003 11:16:17 +0100
From: Guido Draheim [EMAIL PROTECTED]
The problem is in call-mismatch: the library is compiled as 64bit off_t
which makes a call like lseek (int,off_t,int) to be actually an
lseek (int,off64_t,int). When an application is compiled
Paul Eggert schrieb:
Date: Sat, 11 Jan 2003 11:00:57 +0100
From: Guido Draheim [EMAIL PROTECTED]
The end of the discussion can only be to change the compilation
behaviour globally - making 64bit off_t the default if that is
supported by the system, and dropping the settable off_t altogether
Paul Eggert schrieb:
Date: Sat, 11 Jan 2003 18:45:30 +0100
From: Guido Draheim [EMAIL PROTECTED]
The problem only exists when off_t creeps into public headers usable
by third party applications,
Not true. The problem can exist even if the public headers export
only 'int'. For example
Paul Eggert schrieb:
I don't think we should worry about supporting mixed 32- and 64-bit
off_t. All sane programs will use plain 64-bit off_t on modern
platforms. Libraries should be built in 64-bit mode as well. If you
really need a 32-bit off_t library for some strange reason, build it
has gnu.org eaten our mails?
I know atleast of four mails that have been sent but not coming
back through the mail loop to me, nor do they pop up at gmane
within the last dozen hours. Pretty irritating that is... well,
atleast here's the link to gmane in case you have not come across
this
Ville Laurikari schrieb:
The reason: some compilers will happily accept -v or +w1 for
something not intended - they are valid but they do not do what
we want, to just enable additional warning-options.
Have there been problems with the way vl_prog_cc_warnings works? At
least I haven't heard
Ville Laurikari schrieb:
I'm not on the autoconf list so excuse me for possibly repeating stuff
that has been on the list already. Also, if you want me to reply, CC
your list replies to me as well.
there was nothing so far, and even the initial post included your
address, so it is most likely
with the ongoing expansion of ac-archive, it started to problematic
to keep the macros sorted out. There has been a discussion a while
back whether it might make sense to reserve a macro-prefix for
those registered in the ac-archive - the usage of AX_ sounds best.
This AX_ prefix is now detected
I did lately needed again extensions of the old scheme to add
compiler-specific options. The macros being most in usage
where
ac_prog_cc_warnings.m4 (renamed to) vl_prog_cc_warnings.m4
ac_prog_cc_no_writeable_strings.m4 (needed widely around, and)
ac_check_cc_opt.m4 (to add arbritrary
The newest variant for making prefixed config.h defines is now up at
the sfnet ac-archive - I did just found a last bug, and after having
it used in a few projects of mine, I think it is now time to make
them available to the world ;-) ... all the other prefix_config_h
macros are now marked
In a discussion lately, I did observe something that may have
been interesting to many but got by unnoticed - the problems
of largefile support modern unix systems.
First, ALL unix98 system are REQUIRED to support largefile access
in their base installation:
http://cvs.samba.org/cgi-bin/cvsweb/samba/source/configure.in?rev=1.383
The AC_SYS_LARGEFILE macro looks a bit outdated in comparison.
Note also the agreement of the large.file.summit people to use
-D_LARGEFILE_SOURCE as the primary define to enable 64bit off_t.
Dirk wrote:
how would i find out if ipv6 is available (enabled)?
enabled is a runtime problem.
autoconf handles compile/link issues.
That will include to check for a header file
to declare ipv6 symbols and a lib to export
the actual implementations. In general, the
developer docs of your
'omfresourcecreator Guido Draheim /creator' $@
grep Packager $(FROMSPEC) | sed -e 's,Packager *: *, maintainer,' \
-e '/maintainer/s,$$,/maintainer,' $@
grep Summary $(FROMSPEC) | sed -e 's,Summary *: *, title,' \
-e '/title/s
? wrote:
so here are ?y 2 questions:
1) how can i pass the --disable-shared option to the library ./configure
during th ebuild process of my project
2) how to avoid the library o be installed during my project installation
process
thanks for your solutions
Frankly, I would bind the
Markus Werle wrote:
Hi!
Consider the following case:
File VeryImportant.C contains code that really needs some
optimization available. But all other files could (at least during development)
be compiled without optimization, for the sake of not drinking too much coffee
due to long compilation
[EMAIL PROTECTED] wrote:
Dear all,
I compile SDL on ucLinux and want to change the host to mipsel-linux.
I use option as follows:
./configure --host=mipsel-linux
but the host is also the default setup..
What is also the default setup ?
$ sh config.sub mipsel-linux
Balint Joo wrote:
array dimensions at configure time). The package builds a library
which is installed, and config.h gets installed also in the
@prefix@/include
directory.
I then have a second package which needs to use the first one,
and it needs to include the its config.h file.
However, the
Jeff Squyres wrote:
On Thu, 12 Dec 2002, Guido Draheim wrote:
Is there a nice way to solve this problem?
AC_CREATE_PREFIX_CONFIG_H see http://ac-archive.sf.net
it's an old problem of library makers, search the autoconf ML archive
for references. Basic point: do not install config.h
Balint Joo wrote:
Instead I ended up solving the problem the dumb way. I didn't use the
pkh-config.h and AC_DEFINE mechanism. I created a pkg-config.h
file and used dumb substitution a la:
AC_CONFIG_FILE(include/pkg-config.h)
and in the include/pkg-config.h.in file:
that's the way the core
just short annotations, nothing adding lots up in the discusion,
or in other words, I like to support your view in large parts:
Jeff Squyres wrote:
On Thu, 12 Dec 2002, Guido Draheim wrote:
objection refused. The autoconf at its heart is a macro package, simple
as that, no heavy machinery
Lars Segerlund wrote:
I'm trying to find out the os ( build=host ) but i dont want to ship a
config guess, and this seem's a simple operation but I can't find the
macro to use.
Any help ? Please ?
config.guess exists because it is not a simple operation if it shall be
done universally for
Jeff Squyres wrote:
prefixes. But autoconf isn't even giving the user the option to do that
-- these macros will be named PACKAGE_FOO, regardless of what the user
wants.
Please please please give us a way to turn off (or put a prefix in front
of) these macros.
btw, has anyone tried to use a
Soren A wrote:
Hello,
This message is along similar lines to others i read on this list in the
last couple of days.
It occurs to me to ask, before i consider submitting this to an Autoconf
macro collection, for tips on the approach taken. Feedback from the List
is requested.
The
Tom Lord wrote:
are already installed. Call this set the bootstrap packages.
Let's then formally identify a _subset_ of the bootstrap packages,
which are those GNU tools that other (non-bootstrap) GNU packages are
allowed to depend on for the build process. For example, GNU Make
would
Actually, I've been thinking more of AC_MSG_ERROR itself.
It would also hint developers of ac-macros (think of
ac-archive) to remember to push checkpoints and extended
diagnostics into the config.log itself, and so to keep
the user output short and clean. Well, it might be that
it was not
Es schrieb vincent blondel:
I give you here the content of my config.log
why don't you read it?
[guidod@pc3 pfe]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/specs
gcc version 2.96 2731 (Mandrake Linux 8.2 2.96-0.76mdk)
[guidod@pc3 pfe]$ gcc
Es schrieb Peter Eisentraut:
Guido Draheim writes:
tail config.log
Which reminds me, it would be nice if this actually worked.
Currently, tail config.log gives you confdefs.h, before that are the cache
variables. Would it be reasonable to put the tests at the very end?
Nope. Too
Es schrieb Troy Cauble:
I am cleaning up some autoconf scripts to support
multiple builds against the same source, as in
mkdir build_dir1
cd build_dir1
../configure
In the middle of this large autoconf based project
there's a third party module that does not use autoconf.
Es schrieb Guido Draheim:
Es schrieb Troy Cauble:
I am cleaning up some autoconf scripts to support
multiple builds against the same source, as in
mkdir build_dir1
cd build_dir1
../configure
In the middle of this large autoconf based project
there's a third party
http://ac-archive.sf.net/C_Support/ac_prog_cc_warnings.html
see also
http://ac-archive.sf.net/C_Support/ac_prog_cc_strict_prototypes.html
http://ac-archive.sf.net/C_Support/ac_prog_cc_no_writeable_strings.html
Es schrieb Philip Willoughby:
Hi all,
I'm trying to write a pair of macros to
Es schrieb Mark D. Roth:
On Thu May 16 05:59 2002 -0400, Thomas E. Dickey wrote:
aclocal has good intentions, poor design.
I don't really understand why everyone says that like there's nothing
we can do about it. If the design is poor and inconvenient, let's fix
it! That is why it's
Es schrieb Paul Eggert:
From: Mark D. Roth [EMAIL PROTECTED]
Date: Thu, 16 May 2002 12:28:27 -0500
That's fine, as long as it gets invoked automatically when you invoke
autoconf. It should all get done in one step.
Personally, I dislike site directories since
they make it a
Es schrieb Yves Arrouye:
Hi,
I am running into a case where different Autoconf-based packages define the
same macros, giving me plenty of warnings. Is there a way to prefix the
AC_DEFINE'd names with some unique string (or maybe just the ones defined by
Autoconf, such as the HAVE_,
1 - 100 of 168 matches
Mail list logo
