apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Date Thu, 28 Dec 2000 07:54:42 GMT
This is a great idea :-)

My suggestion though... let's follow the ansi/posix/unix spec and simply
#define WANT_APR_STDIO_H before including apr... e.g. we know what the
offical stdio.h should have, so if it's a matter of including stdio plus
stdlib plus conio on win32, then that's what the win32 port does.

Refer to everything by some -very- consistent id (the spec is best) and
we should have a mission + a reasonable chance of success.

One thing that is guarenteed to screw us up, however, is the sequence of
defines and include "apr.h" ... but I know you already have a great 
solution thought up :-)

Bill

> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Friday, December 22, 2000 4:21 PM
> To: new-httpd@apache.org; dev@apr.apache.org
> Subject: Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
> 
> 
> On Fri, Dec 22, 2000 at 04:57:10PM -0500, greg wrote:
> > Greg Stein wrote:
> > > 
> > >                   I'm thinking that we want to have a
> > > file describe the features it needs, then ask APR to get 
> them for us.
> > > 
> > > For example:
> > > 
> > > #define APR_WANT_STDIO 1
> > > #define APR_WANT_MEM_FUNCS 1
> > > #define APR_WANT_STR_FUNCS 1
> > > #include "apr_want.h"
> > > 
> > 
> > Love the concept...don't like the timing. Can it wait until 
> after the
> > beta? 
> 
> I believe the beta is indefinitely delayed. It'll be at least a week.
> 
> That said: I'm out of town Saturday thru Thursday, so I 
> wouldn't be doing
> this for a while anyways.
> 
> > I've been fighting OS/390 build problems for over a day 
> because of the
> > apr-util/.libs change.
> 
> If we reverted that change and just went against the .la 
> again, would that
> work for you? The use of .libs should never have happened.
> 
> > Sounds like it's giving David Reed some grief also.
> 
> That is also simply fixed by passing --disable-shared from 
> the top-level
> configure. Although, we should be able to work with shared 
> libraries, so we
> need to find out what his "human intervention" really means. 
> In other words,
> --disable-shared simply hides other problems that need to be 
> fixed. By the
> time that we release, we should not be using --disable-shared.
> 
> Cheers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 

Mime
View raw message