apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <jwool...@virginia.edu>
Subject Re: Inline problems on MingW
Date Mon, 30 Aug 2004 17:08:54 GMT
On Mon, 30 Aug 2004, Gisle Vanem wrote:

> Okay, I worked on the original problem and found a viable fix; Leave the
> APR_INLINE in apr.hw as-is:
>
> #define APR_INLINE __inline
>
> But in headers like arch\win32\apr_arch_atime.h, with inline code do at
> top:
>
> #ifdef __GNUC__
> #undef  APR_INLINE
> #define APR_INLINE extern __inline
> #endif

Um, why not just do this in apr.hw?

#ifndef __GNUC__
#define APR_INLINE __inline
#else
#define APR_INLINE extern __inline
#endif

Seems the cleanest way to me by far.  That is, after all, what apr.h is
for.

> Another problem is that "extern __inline" code will *not* be inlined with
> "gcc -O0" (__NO_INLINE__ becomes a built-in). So a gcc-built DLL must
> use -O1 or higher unless we "sweep up" such inline functions in a src-file.

This is surely not a problem, right?  Only debug builds will use -O0, in
which case you don't really want inlining anyway.

> BTW. Could we please have a bit more intuitive suffixes to the
> config-files? I.e. apr.h.netware, apr.h.win32 etc. Just my 0.2€

I was under the impression that the suffixes were short to be more
8.3-friendly (silly legacy file systems).  Could be wrong.

--Cliff

Mime
View raw message