On Mon, Jan 30, 2012 at 8:47 AM, Pete Batard <pbat...@gmail.com> wrote:
> On 2012.01.30 02:22, Rocky Bernstein wrote: > >> Removing the requirement cdio_config.h is probably okay. However removing >> it ultimately from the distribution is a little bit different. >> >> The file serves to document how libcdio was compiled. So as such I think >> it >> should remain. Also I'm a little concerned about compatibility and so >> again, if a program had been using this, although we may decide to >> deprecate it, that is different from removing it. >> > > Good point. I hadn't thought of that, and I agree that keeping a copy of > the config is something we want. > > I'll add a commit that restores the copying of config.h to > include/cdio/cdio_config.h > > I don't think cdio_unconfig.h needs to be restored though - do you see it > differently? I think what really needed is a transformation of config.h which prepends, say CDIO_ to a number of the defines like the PACKAGE* defines and other defines like _FILE_OFFSET_BITS, _LARGEFILE_SOURCE and WORDS_BIGENDIAN. With this, such a modified header can be included safely in other programs that want to test or or present the features of the libcdio that gets used. In particular, I would probably use this information in the various libcdio bindings for Perl, Python and Ruby so that those programs can get at such information too. Things like _POSIX_1_SOURCE aren't needed. But worse, this along with _LARGEFILE_SOURCE could with alter how other C programs want to configure themselves. So in the absence of this which was expedient, cdio_unconfig.h was also expedient. I will plan on doing the right thing to process config.h to a safe cdio_config and then we won't need cdio_unconfig.h > > I think Thomas Schmitt's and/or xorriso may use cdio_config.h, so I'd be >> interested to get feedback from him after the dust settles in the pbatard >> branch. >> > > I'd like to have some feedback to. > > Right now, I'm at a point where I can use the files from libcdio-pbatard > into my app and compile them almost as is, in all of MinGW and MSVC, so > what remains is a little bit of cleanup, and cross feeding patches for > smaller issues that may appear in one environment and not the other. > > > Replacing stdbool and inline seems fine. However we should let folks test >> this to see how it goes. >> > > Agreed. I'm more concerned about the (currently) mandatory sys/types.h > requirement, as well as the removal of unistd.h at the moment. > > Regards, > > /Pete > >
