From cvs-return-4034-apmail-apr-cvs-archive=apr.apache.org@apr.apache.org Thu Aug 22 20:16:24 2002 Return-Path: Delivered-To: apmail-apr-cvs-archive@apr.apache.org Received: (qmail 30137 invoked by uid 500); 22 Aug 2002 20:16:24 -0000 Mailing-List: contact cvs-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: dev@apr.apache.org Delivered-To: mailing list cvs@apr.apache.org Received: (qmail 30124 invoked from network); 22 Aug 2002 20:16:24 -0000 Date: 22 Aug 2002 20:16:23 -0000 Message-ID: <20020822201623.18281.qmail@icarus.apache.org> From: gstein@apache.org To: apr-cvs@apache.org Subject: cvs commit: apr STATUS X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N gstein 2002/08/22 13:16:23 Modified: . STATUS Log: "A dump truck... a *yellow* dump truck..." -- kid on Emergency, circa mid 70's Revision Changes Path 1.174 +25 -13 apr/STATUS Index: STATUS =================================================================== RCS file: /home/cvs/apr/STATUS,v retrieving revision 1.173 retrieving revision 1.174 diff -u -r1.173 -r1.174 --- STATUS 19 Aug 2002 21:38:46 -0000 1.173 +++ STATUS 22 Aug 2002 20:16:23 -0000 1.174 @@ -33,12 +33,16 @@ HIBYTE, LOBYTE) apr.hw (NO_USE_SIGACTION) + 1.0 showstopper (not 0.9.x): gstein + * complete the efforts started by DougM for cleaner fn naming conventions: see proposed name changes in renames_pending and offer up any additions/vetos/clarifications. DougM offered to complete the work with his nifty perl rename script at the hackathon. + 1.0 showstopper (not 0.9.0): gstein + * When Win32 apr_proc_create was fixed, the apr_proc_t hproc member was added for that platform. That's a problem (and was when pid was abused as well) since nobody goes and cleans @@ -46,19 +50,27 @@ since apr_proc_create didn't allocate the apr_proc_t storage. (Aren't transparent types swell?) Suggestions? - * extract the MAJOR version from apr_version.h and pass it to - libtool for use in applying version numbers to the shared - libraries. + 1.0 showstopper (not 0.9.0): gstein * Change apr_initialize to take the expected version (in some form) and return an error code if the requirement isn't satisfied. + gstein: -1 + Justin says: "Relying solely on the run-time linker isn't enough to guarantee versioning." + Greg says: "yup. but now the libraries have different names. + -lapr-1 and -lapr-2. further, we can always add a + utility function to check (the minor rev), rather + than monkey with the initialization itself. the + runtime linker will catch new function requirements + across minor rev upgrades, but will not catch new + constants." CURRENT VOTES: + RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * The return type of a thread function (void *) is inconsistent with @@ -180,7 +192,7 @@ * add a version number to apr_initialize() as an extra failsafe against (APR) library version skew. MsgID: - Status: Greg +1 (volunteers), Jeff +1, Ryan +1, Tony -0(?), david +1 + Status: Greg -1, Jeff +1, Ryan +1, Tony -0(?), david +1 * add apr_crypt() and APR_HAS_CRYPT for apps to determine whether the crypt() function is available, and a way to call it (whether it is @@ -225,14 +237,14 @@ Justin says: Both thread and file have the accessors now. Any others? Status: Greg volunteers - * I think apr_open_stderr() and friends dup() the descriptor. That - would allow the new/returned file to be closed (via pool cleanup - or manually) without accidentally closing stderr/out. - Justin says: Is this "I think it should?" - - * need to export the shared library extension (e.g. ".so") for the - platform. clients need to use this to construct filenames to - pass to apr_dso_load() + * I think apr_open_stderr() and friends *should* dup() the + descriptor. That would allow the new/returned file to be closed + (via pool cleanup or manually) without accidentally closing + stderr/out. + + * need to export (in code, not just build scripts) the shared + library extension (e.g. ".so") for the platform. clients need to + use this to construct filenames to pass to apr_dso_load() -- note on Win32 we distinguish 'apache module' names from other 'loadable module' names, so be careful with Apache's directive.