apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: cvs commit: apr configure.in
Date Wed, 21 Feb 2001 10:27:26 GMT
On 21 Feb 2001, Jeff Trawick wrote:

> martin@apache.org writes:
>
> > martin      01/02/21 07:51:43
> >
> >   Modified:    include  apr_general.h
> >                file_io/unix Makefile.in
> >                .        configure.in
> >   Added:       file_io/unix mktemp.c
> >   Log:
> >   Add mktemp() and mkstemp() emulation for systems which don't have it.
> >   Jean-Frederic writes:
> >    I have tested Apache2.0 with a ReliantUNIX machine. This machine has a
> >    SVR4 Unix implementation.
> >    To compile correctly the -DXTI_SUPPORT should be added to CFLAGS (I have
> >    done it when calling configure), and I have added a mkstemp() because it
> >    is not in the default runtime library.
> >    I have reused and enhanced an mkstemp() routine from FreeBSD. Find
> >    enclosed the needed patch to test for mkstemp() and to use ap_mkstemp()
> >    when needed.
> >
> >   Submitted by:	Jean-Frederic Clere <jfrederic.clere@fujitsu-siemens.com>
> >
> >   Revision  Changes    Path
> >   1.53      +6 -0      apr/include/apr_general.h
> >
> >   Index: apr_general.h
> >   ===================================================================
> >   RCS file: /home/cvs/apr/include/apr_general.h,v
> >   retrieving revision 1.52
> >   retrieving revision 1.53
> >   diff -u -u -r1.52 -r1.53
> >   --- apr_general.h	2001/02/16 04:15:44	1.52
> >   +++ apr_general.h	2001/02/21 15:51:42	1.53
> >   @@ -143,6 +143,12 @@
> >    #define memmove(a,b,c) bcopy(b,a,c)
> >    #endif
> >
> >   +#if (!HAVE_MKSTEMP)
> >   +#define mkstemp(a) ap_mkstemp(a)
> >   +#define mkstemps(a,b) ap_mkstemp(a,b)
> >   +#define mkdtemp(a) ap_mkdtemp(a)
> >   +#endif
>
> I guess I missed my chance to comment before :)  I'll take this
> opportunity to raise a few issues, particularly since this breaks the
> Tru64 (and probably other platforms) build.
>
> If APR wants to provide a wrapper for mkstemp() which works
> everywhere, that is cool, but the interface has to be namespace
> protected.   I don't think this stuff goes in apr_general.h.

+1.

>
> Unless somebody disagrees, I'm going to trim down the usage a bit for
> now.  I'll get the stuff out of apr_general.h.  We detect whether or
> not there is mkstemp().  If not then the code in  mktemp.c will be
> exposed.  If the system already has mkstemp(), then the code in
> mktemp.c will be hidden and we don't risk compile breakage (it looks
> pretty fragile to me).
>
> To expose it properly as an APR API, we'd need a little doc in
> apr_file_io.h (I guess).  Also, we'd need to decide whether
> apr_mkstemp() is always a function or is a macro on systems which
> provide mkstemp().

Personally, I would just always make it a function.  That allows us to
control how it works, and ignore any small platform differences.  Just an
opinion though.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message