httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: cvs commit: apache-2.0/src/lib/apr/time/beos access.c
Date Sat, 11 Sep 1999 08:40:47 GMT

In article <> you wrote:
> wrote:
>>   Modified:    src/lib/apr
>>                src/lib/apr/file_io/beos fileacc.c fileio.h open.c
>>                         readwrite.c
>>                src/lib/apr/lib apr_getpass.c
>>                src/lib/apr/test htdigest.c
>>                src/lib/apr/threadproc/beos proc.c threadproc.h
>>                src/lib/apr/time/beos access.c
>>   Added:       src/lib/apr/threadproc/beos apr_proc_stub.c procsup.c
>>   Log:
>>   More changes to bring BeOS up to the UNIX APR level.  Also a few changes to
>>   some test programs to make them more portable.  Lastly, a work around for a
>>   BeOS bug that makes fork potentially dangerous.
>>   Submitted by:  David Reid
> I think this patch exemplifies some of the worry that myself (and a few
> others? Jim?) shared at the start of this project. Namely, that APR is
> sliced rigidly along OS lines, rather than "standard + platform-specific
> tweaks" lines. As a result, this creates a multiple-path maintenance
> nightmare.

Yes, that's why I complained about the subdir approach of APR in the past,
too.  I think there should be only _ONE_ source per functionality and if
platform specific things are needed they should be done with some #ifdef's
based on feature test macros which were determined by Autoconf. Ryan, please
think about this again. The current approach is what I usually call
"semi-portable", i.e. if something was ported to N platforms but on the
(N+1)th platform one has to hack manually to get it running there.  I would
appreciate if APR would be done the implicitly portable way...

                                       Ralf S. Engelschall

View raw message