[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rocky Bernstein
Subject: Re: [Libcdio-devel] removal of include/cdio/cdio_config.h
Date: Mon, 30 Jan 2012 21:36:53 -0500

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
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

So in the absence of this which was expedient, cdio_unconfig.h was also

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]