Re: [Libcdio-devel] removal of include/cdio/cdio_config.h

[Rocky Bernstein]

On Mon, Jan 30, 2012 at 8:47 AM, Pete Batard <address@hidden> 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
>
>