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
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
From: "Greg Stein" <[EMAIL PROTECTED]>
To: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
> On Wed, Nov 29, 2000 at 11:08:14AM -0800, William A. Rowe, Jr. wrote:
> > From: "Greg Stein" <[EMAIL PROTECTED]>
> > To:
> >
> >
> > > I just made some changes to mpm/winnt/, but couldn't compile them. Sinc
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
> > > export or anything.
> >
> > Unfortunately, as Jim fou
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=""
> >>
[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 11:08:14AM -0800, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <[EMAIL PROTECTED]>
> To:
>
>
> > I just made some changes to mpm/winnt/, but couldn't compile them. Since it
> > was basically just tweaking the types, could you update from CVS and see if
> > it still co
> > > > +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}
> > > >
From: "Greg Stein" <[EMAIL PROTECTED]>
To:
> I just made some changes to mpm/winnt/, but couldn't compile them. Since it
> was basically just tweaking the types, could you update from CVS and see if
> it still compiles properly?
Dirtier than , but it -does- compile. Lots of emits on mispar
On Wed, Nov 29, 2000 at 08:08:54AM -0800, [EMAIL PROTECTED] wrote:
> On Wed, 29 Nov 2000, Greg Stein wrote:
> > On Tue, Nov 28, 2000 at 09:31:54PM -, [EMAIL PROTECTED] wrote:
>...
> > >...
> > > +dnl
> > > +dnl APR_DOEXTRA
> > > +dnl
> > > +dnl Handle the use of EXTRA_* variables.
> >
On Wed, Nov 29, 2000 at 08:01:05AM -0500, Jeff Trawick wrote:
> [EMAIL PROTECTED] writes:
>
> > gstein 00/11/28 23:41:27
> >
> > Modified:include apr_getopt.h
> >misc/unix getopt.c
> >test testargs.c
> > Log:
> > Add an extra const into the geto
On Wed, Nov 29, 2000 at 07:59:41AM -0800, [EMAIL PROTECTED] wrote:
> On Tue, 28 Nov 2000, Brian Behlendorf wrote:
>
> > On Tue, 28 Nov 2000, Greg Stein wrote:
> > > Okay... we seem to have some general agreement to make a "non-core" APR
> > > package that contains the "purely portable" items. With
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
> > Added: src hints.m4
> > Log
On Tue, 28 Nov 2000, Brian Behlendorf wrote:
> On Tue, 28 Nov 2000, Greg Stein wrote:
> > Okay... we seem to have some general agreement to make a "non-core" APR
> > package that contains the "purely portable" items. With that in mind, here
> > are my rough ideas/notes on this:
> >
> > *) create
--- Greg Stein <[EMAIL PROTECTED]> wrote:
> Well, it has been suggested that we create a new "APR utility" library. The
> discussion on that *just* opened today. It looks like we have several +1 on
> the concept, and I posted an outline of my thoughts on it.
It's cool with me. That thread starte
[EMAIL PROTECTED] writes:
> gstein 00/11/28 23:41:27
>
> Modified:include apr_getopt.h
>misc/unix getopt.c
>test testargs.c
> Log:
> Add an extra const into the getopt functions. We never attempt to modify any
> of the data, so the const is pr
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 two files, one in APR
On Tue, Nov 28, 2000 at 06:45:03PM -0800, Brian Behlendorf wrote:
> On Tue, 28 Nov 2000, Greg Stein wrote:
> > Okay... we seem to have some general agreement to make a "non-core" APR
> > package that contains the "purely portable" items. With that in mind, here
> > are my rough ideas/notes on this:
Well, it has been suggested that we create a new "APR utility" library. The
discussion on that *just* opened today. It looks like we have several +1 on
the concept, and I posted an outline of my thoughts on it.
Presuming nobody pops up with a "Dood. Big, Bad Idea.", then we'll probably
start on th
--- "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
> But any which way, we should be providing these simple data types to
> make c coding easier and more portable across platforms.
I was thinking the same thing.
At the risk of adding too much complexity, let me make a suggestion. Part of
th
On Tue, 28 Nov 2000, Greg Stein wrote:
> Okay... we seem to have some general agreement to make a "non-core" APR
> package that contains the "purely portable" items. With that in mind, here
> are my rough ideas/notes on this:
>
> *) create a new CVS module: /home/cvs/aprutil
>[ other suggested
Greg Stein wrote:
On Wed, Nov 29, 2000 at 02:59:12AM +0100, Branko Cibej wrote:
Greg Stein wrote:
I think that's all that I've got. Thoughts? Comments?
Maybe tweak APR scrpits so that they automagically find, configure and
build APRUTIL if somebody happens to unpack it (or checkout) in the APR
to
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 autoconf macros.
To tel
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 imagine that it is possible to discover whe
On Wed, Nov 29, 2000 at 02:59:12AM +0100, Branko Cibej wrote:
> Greg Stein wrote:
>
> > I think that's all that I've got. Thoughts? Comments?
>
> Maybe tweak APR scrpits so that they automagically find, configure and
> build APRUTIL if somebody happens to unpack it (or checkout) in the APR
> to
Greg Stein wrote:
I think that's all that I've got. Thoughts? Comments?
Maybe tweak APR scrpits so that they automagically find, configure and
build APRUTIL if somebody happens to unpack it (or checkout) in the APR
top-level directory? Then those users of APR that need APRUTIL too will
only have
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. Doing so would
make
On Tue, Nov 28, 2000 at 05:03:49PM -0800, William A. Rowe, Jr. wrote:
> From: <[EMAIL PROTECTED]>
> To: "Greg Stein" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> >
> > > We can stratify and create as many layers in Apache as we want to put up
> > > with. But when we're talking about a *portabil
Okay... we seem to have some general agreement to make a "non-core" APR
package that contains the "purely portable" items. With that in mind, here
are my rough ideas/notes on this:
*) create a new CVS module: /home/cvs/aprutil
[ other suggested names? aprkitchensink? :-) ]
[ I'll refer to it
From: <[EMAIL PROTECTED]>
To: "Greg Stein" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
>
> > We can stratify and create as many layers in Apache as we want to put up
> > with. But when we're talking about a *portability* library, then it should
> > focus on just that.
>
> All of the code we are t
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 work on any p
31 matches
Mail list logo
