apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Clark <mich...@metaparadigm.com>
Subject Re: Extended Attributes Support
Date Sat, 22 Dec 2007 06:14:47 GMT
William A. Rowe, Jr. wrote:
> I'd go for a subdir option (xattrs/solaris.c, xattrs/freebsd.c, etc)
> where the parent apr_xattrs.c in the unix directory just sucks in
> the correct implementation by ifdef tests...

I went for this approach (as it was Davi's initial suggestion for this 
directory structure also).

It works. Only (minor) issue is the build-outputs.mk sources 
dependencies for the files in the file_io/unix/xattr subdirectory don't 
get generated.

>> Not sure how I would integrate this into the build (perhaps
>> having a single #if that create empty compilation units for
>> the inactive platforms?).
> the last #else case in apr_xattrs.c falls into APR_ENOTIMPL stubs.
>> Test cases should go into a new unit - not linked into testall?
> yes linked in.  APR_ENOTIMPL just isn't a fail-case.

OK. I have it linked in and followed the threads approach of using a 
conditional to define an unimplemented test and have it succeed with the 
unimplemented message.

>> Also what is the procedure for proposing and adding a new API like
>> this. I guess my patch should have it disabled by default and enabled
>> with a configure flag - say --enable-xattrs (or autodetected and enabled
>> on supported platforms)?
> Nope - just enable it; this is on trunk so we have some time to get
> things right.  When folks deploy conditional features it makes it
> a total nightmare for the next package which shares the libs.

OK. I have it enabled by default and symbols always will be linked in 
plus there is a --disable-xattr option which will pull in the ENOTIMPL 
versions, useful if someone has broken headers.


View raw message