On Fri, 2 Mar 2001, Greg Stein wrote:
> On Thu, Mar 01, 2001 at 10:32:21PM -0800, [EMAIL PROTECTED] wrote:
> > On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> > > On Thu, Mar 01, 2001 at 09:40:44PM -0800, [EMAIL PROTECTED] wrote:
> > > > We still need to APR namespace protection. We tried to not nam
Roy T. Fielding wrote:
>
> Correct me if I am wrong, but all these changes and problems are
> simply to reduce the three parameters of a standard autoconf macro
> to one parameter in an APR-specific macro? If so, then -1 --> that
> kind of change is why our buildconf setup is so much less portabl
Roy T. Fielding wrote:
>
> Then we should fix the cause of that goofyness, which is due to all
> APR defines being set to "0" or "1" instead of undefined/defined.
> Fixing that would remove the cause of all those other subtle typos and
> bugs, in addition to these above, and leave us with a standa
On Thu, Mar 01, 2001 at 10:32:21PM -0800, [EMAIL PROTECTED] wrote:
> On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> > On Thu, Mar 01, 2001 at 09:40:44PM -0800, [EMAIL PROTECTED] wrote:
> > > We still need to APR namespace protection. We tried to not namespace
> > > protect things to begin with, and
On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> On Thu, Mar 01, 2001 at 09:40:44PM -0800, [EMAIL PROTECTED] wrote:
> > We still need to APR namespace protection. We tried to not namespace
> > protect things to begin with, and Apache and APR were conflicting
> > horribly.
>
> Because the method I des
On Thu, Mar 01, 2001 at 09:40:44PM -0800, [EMAIL PROTECTED] wrote:
>
> We still need to APR namespace protection. We tried to not namespace
> protect things to begin with, and Apache and APR were conflicting
> horribly.
Because the method I described was not used.
> Add to that, that we define
We still need to APR namespace protection. We tried to not namespace
protect things to begin with, and Apache and APR were conflicting
horribly. Add to that, that we define our own macros that no other
package should have.
We have been down the road of exposing non-namespace protected macros
be
> Changing from "1" and "0" to def, undef wouldn't change anything at all.
> The exact same logic is required, and the same general variables are
> required. The differences between the two are incredibly minor, because
> we want to use namespace protected macros.
If we changed to def/undef and w
On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> On Thu, Mar 01, 2001 at 09:39:22PM -0500, Cliff Woolley wrote:
> > On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> >
> > > Correct me if I am wrong, but all these changes and problems are
> > > simply to reduce the three parameters of a standard autoconf m
On Thu, Mar 01, 2001 at 09:39:22PM -0500, Cliff Woolley wrote:
> On Thu, 1 Mar 2001, Roy T. Fielding wrote:
>
> > Correct me if I am wrong, but all these changes and problems are
> > simply to reduce the three parameters of a standard autoconf macro
> > to one parameter in an APR-specific macro?
>
On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> Correct me if I am wrong, but all these changes and problems are
> simply to reduce the three parameters of a standard autoconf macro
> to one parameter in an APR-specific macro?
That's one way to look at it, yeah, but that doesn't capture all of the
b
Correct me if I am wrong, but all these changes and problems are
simply to reduce the three parameters of a standard autoconf macro
to one parameter in an APR-specific macro? If so, then -1 --> that
kind of change is why our buildconf setup is so much less portable
than typical configure scripts,
Greg Stein <[EMAIL PROTECTED]> writes:
> I'd rather we find out what is wrong with BSD m4.
News flash: it's not just BSD m4 -- my Debian Linux box also cannot
build APR now, with exactly the same errors as Ben reported from BSD.
galois$ m4 --version
GNU m4 1.4
galois$
I have not been f
More weirdness... If I change the below to:
APR_FOREACH([
[if test "$ac_cv_header_]translit(eachval,[/+-.],[_p__])" = "yes"; then
dnl note: this translit() maps "/" to "_" and omits ".". the third arg
(note the rearrangements in the translit strings), configure looks
like:
for ac_hdr i
Greg Stein wrote:
>
> I'd rather we find out what is wrong with BSD m4.
>
I do see the strip-off-last-h-occasionally problem with Gnu m4.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
It solves it, but it is much less effective than the approach that is
currently in there. Specifically, it invokes a bunch of subshells and seds
for each and every header. My change last night totally avoids that by
moving the effort into m4 rather than runtime.
I'd rather we find out what is wron
[EMAIL PROTECTED] wrote:
>
> Jim just posted a patch which should solve the problem without using
> GNUm4.
>
Here it is again... I'd appreciate feedback on it, because it
looks like it solves the problem. At the least, you'll
see no diff in your apr.h and apr_private.h files, at best,
you'll see
On Tue, Feb 27, 2001 at 11:43:06AM -0600, Ben Collins-Sussman wrote:
>
> Sorry, I'm confused here; my FreeBSD 4.2 system has /usr/bin/m4 and
> /usr/local/bin/gm4. Do I need to do some icky softlinking to make APR
> use gm4? Or is there a better solution?
I believe you should be able to say:
M4
Jim just posted a patch which should solve the problem without using
GNUm4.
Ryan
On 27 Feb 2001, Ben Collins-Sussman wrote:
>
> Sorry, I'm confused here; my FreeBSD 4.2 system has /usr/bin/m4 and
> /usr/local/bin/gm4. Do I need to do some icky softlinking to make APR
> use gm4? Or is there a
Sorry, I'm confused here; my FreeBSD 4.2 system has /usr/bin/m4 and
/usr/local/bin/gm4. Do I need to do some icky softlinking to make APR
use gm4? Or is there a better solution?
20 matches
Mail list logo
