Hmmm... right now, if CFLAGS (et.al.) set, the hints.m4 stuff is
*not* used (they are only set if these env vars are null)...
I'm thinking now that that's not the right thing. These
should be set (added) no matter what.
The reason for the current behavior is so that people can &quo
Jim Jagielski <[EMAIL PROTECTED]> writes:
> Hmmm... right now, if CFLAGS (et.al.) set, the hints.m4 stuff is
> *not* used (they are only set if these env vars are null)...
> I'm thinking now that that's not the right thing. These
> should be set (added) no matter what.
Note that hints.m4 is a "last resort". The hope is that everything can be
determined via autoconf feature tests, rather than per-platform tweaks.
I would imagine that it is possible to discover whether
_XOPEN_SOURCE_EXTENDED is need by writing an autoconf test. Doing so would
make it w
Greg Stein wrote:
Note that hints.m4 is a "last resort". The hope is that everything can be
determined via autoconf feature tests, rather than per-platform tweaks.
I would imagine that it is possible to discover whether
_XOPEN_SOURCE_EXTENDED is need by writing an autoconf test. Doin
On Wed, Nov 29, 2000 at 02:41:58AM +0100, Branko Cibej wrote:
> Greg Stein wrote:
>
> > Note that hints.m4 is a "last resort". The hope is that everything can be
> > determined via autoconf feature tests, rather than per-platform tweaks.
> >
> > I would
Greg Stein wrote:
I would imagine you're right. I'll try to come up with an autoconf test
for that, then.
Oh, don't put yourself back. My point was more for future work in hints.m4
or if somebody wants to spend some time trying to clean some hints out of
there, in favor of auto
On Tue, Nov 28, 2000 at 09:31:54PM -, [EMAIL PROTECTED] wrote:
> rbb 00/11/28 13:31:53
>
> Modified:src acinclude.m4 configure.in
>.apr_common.m4 hints.m4
> Added: src hints.m4
> Log:
> Split the hints file into
On Wed, 29 Nov 2000, Greg Stein wrote:
> On Tue, Nov 28, 2000 at 09:31:54PM -, [EMAIL PROTECTED] wrote:
> > rbb 00/11/28 13:31:53
> >
> > Modified:src acinclude.m4 configure.in
> >. apr_common.m4 hints.m4
> >
_DEFUN(APR_DOEXTRA, [
> > > + for i in CFLAGS LDFLAGS LIBS
> > > + do
> > > +eval APR_TMP=\$EXTRA_$i
> > > +if test -n "$APR_TMP"; then
> > > + eval $i=\"\$$i $APR_TMP\"
> > > + eval export $i
> >
> > > > +AC_DEFUN(APR_DOEXTRA, [
> > > > + for i in CFLAGS LDFLAGS LIBS
> > > > + do
> > > > +eval APR_TMP=\$EXTRA_$i
> > > > +if test -n "$APR_TMP"; then
> > > > + eval $i=\"\$$i $APR_TMP\"
> > > > + eval export $i
> > > > + eval unset EXTRA_${i}
> > > >
[EMAIL PROTECTED] wrote:
Ah. I think I understand. Wouldn't the above be simpler and more obvious if
we wrote it like:
AC_DEFIN(APR_DOEXTRA, [
CFLAGS="$CFLAGS $EXTRA_CFLAGS"
EXTRA_CFLAGS=""
LDFLAGS="$LDFLAGS $EXTRA_LDFLAGS"
EXTRA_LDFLAGS=""
LIBS="$LIBS $EXTRA_LIBS"
EXTRA_LIBS=""
])
Pres
On Wed, Nov 29, 2000 at 09:46:51PM +0100, Branko Cibej wrote:
> [EMAIL PROTECTED] wrote:
>
> >> Ah. I think I understand. Wouldn't the above be simpler and more obvious if
> >> we wrote it like:
> >>
> >> AC_DEFIN(APR_DOEXTRA, [
> >> CFLAGS="$CFLAGS $EXTRA_CFLAGS"
> >> EXTRA_CFLAGS=""
> >>
Jim Jagielski wrote:
>
> I need to check what it's being done for, but the reason for the
> exports and the evals is because you need to "protect" the use of
> the vars until you actually need to use them. Recall that autconf
> simply cuts and pastes, so it will see what they are defined as
> at t
You know, back-pedaling a little bit, the current setup is
easily expandable, just by adding another variable name
to the 'for i...' line. Lots of duplicated code.
How about if I just better explain the "magic"?
--
===
Jim
Greg Stein wrote:
>
> > > I see that this came from apr/hints.m4, but I don't understand what it is
> > > really doing here. What is this extra magic?
> > >
> > > AFAIK, all we need to do is set the variables, and that is that. No fancy
> > &g
On 12 Jan 2001 17:57:03 -, [EMAIL PROTECTED] wrote:
>dreid 01/01/12 09:57:02
>
> Modified:. hints.m4 configure.in
> Log:
> The file_as-socket check wasn't getting picked up correctly, so this
> corrects that for BeOS and OS/2. Untested for OS/2
/12 09:57:02
> >
> > Modified:.hints.m4 configure.in
> > Log:
> > The file_as-socket check wasn't getting picked up correctly, so this
> > corrects that for BeOS and OS/2. Untested for OS/2 so Brian?
>
> Err, well it was working fine for me the way it
day, January 13, 2001 1:30 PM
Subject: Re: cvs commit: apr hints.m4 configure.in
> I'd recommend we back it out then, unless it *really* didn't work for
> David the old way... Maybe BeOS and OS/2 weren't including the right
> name?
>
> Brian Havard wrote:
> >
&
David Reid wrote:
>
> Nope, it *REALLY* didn't work on BeOS the old way. I did some testing and
> found that the value wasn't being seen by configure at all and so without
> this it's broken. It seems to be some strange thing about the shell on
> BeOS, but if you want more info then email me dir
Hello,
while waiting for Mingw+MSys support, I noticed this piece of text into
build/apr-hints.m4:
dnl gcc (3.4.2 at least) seems to mis-optimize at levels greater than
dnl -O0 producing link-time errors. The user can override by
dnl explicitly passing a CFLAGS value to configure.
dnl
dnl
On Mon, Dec 22, 2003 at 10:43:49PM -, Jeff Trawick wrote:
> Fix xlate.c compile failure on AIX 5.2.
..
> --- apu-hints.m428 May 2003 04:45:46 - 1.3
> +++ apu-hints.m422 Dec 2003 22:43:49 - 1.3.2.1
> @@ -24,7 +24,7 @@
...
> -*-ibm-aix*)
Joe Orton wrote:
On Mon, Dec 22, 2003 at 10:43:49PM -, Jeff Trawick wrote:
Fix xlate.c compile failure on AIX 5.2.
..
--- apu-hints.m4 28 May 2003 04:45:46 - 1.3
+++ apu-hints.m4 22 Dec 2003 22:43:49 - 1.3.2.1
@@ -24,7 +24,7 @@
...
-*-ibm-aix
07:57:46PM -, [EMAIL PROTECTED] wrote:
> sascha 01/01/05 11:57:46
>
> Modified:. hints.m4
> Log:
> Builds nicely without -DHPUX10, so remove the respective hint.
>
> Revision ChangesPath
> 1.33 +0 -1 apr/hint
23 matches
Mail list logo
