[ moved to [email protected] ] On Fri, Dec 22, 2000 at 10:06:54AM -0800, [EMAIL PROTECTED] wrote: > > minor issues which will come up: > > > > APR (or projects which APR developers work on) stops caring about > > some test and the APR_HAVE_xxx is removed from apr.h => this is a > > bug because it can break some app we've never heard of; in other > > words, we'll have a slow growth in configure tests which we may stop > > caring about > > This is something the APR developers are going to need to start to be > aware of. Basically, we are creating a library now, instead of an > application. This comes with a different set of rules for developers. It > should be very difficult, if not almost impossible, for us to remove a > macro or function from APR.
It does become difficult, but we can do this in major revisions of the library. That will create a "porting" effort to upgrade to another major rev, but it is fine from a compile/link standpoint -- shared libs have revision numbers and an app build against APR 1.0 won't accidentally try and load APR 2.0 instead. > I worked for Digital for a brief period on the team that did the C > Run-Time library, and it was almost impossible to remove a feature, we > need to follow that same model. If you look at how APR has grown, we have > very rarely added something that we didn't REALLY need. The idea is that > if we don't need it, we don't want to support forever, so we don't add > it. Yup. I heard some of the same nightmares from the CRTL folks at Microsoft. Backwards *and* forwards compatibility is a huge effort. It can be quite painful to do :-) > > apps don't necessarily gain when there is a hodge-podge of tests > > performed by APR and tests performed by the app; if the app has to > > perform tests at all, it is better off doing them itself > > The problem is when there is a test that both APR and the app have to > make. The thing is that we don't want apps to make any test that APR is > already doing, because it just gets confusing. Also one of the biggest > complaints about Apache before it started using APR for the header > checking, was that Apache was duplicating all of the tests that APR was > making. If APR is a good portable runtime, then apps shouldn't need to > test for anything that APR is already testing for. True, but these APR_HAVE_*_H macros are kind of an edge case. As Jeff points out, they aren't always needed by APR. However, I think they're suspicious to begin with, and I think that I've got a good solution to them. > > apps may not want to respect our judgement on subtle issues; take > > mmap() for example; we originally had a test for mmap() which failed > > on OS/390... APR didn't use the part which failed, Single Unix (or > > some doc I read) cautioned against the use of that feature, etc.; > > now our idea of HAVE_MMAP (and thus APR_HAVE_MMAP) is based on > > something that is closely related to our code... similar with > > HAVE_GETADDRINFO (and thus APR_HAVE_IPV6)... > > In cases like this, the app has the option to do it's own checking, and > ignore APR. This is why APR has namespace protected all of its > checks. But, if the app does it's own check, then it is likely to remove > some degree of portability. Remember that APR tends to do a lowest common > demoninator type of checking, so that we only support what we can support > cross-platform. See my other note for increasing the portability of #include. > > Happy holidays... > > Right back at yah :-) Ditto, all! Cheers, -g -- Greg Stein, http://www.lyra.org/
