libcdio-devel
[Top][All Lists]
Advanced

[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: Sun, 29 Jan 2012 21:22:30 -0500

On Sun, Jan 29, 2012 at 10:36 AM, Pete Batard <address@hidden> wrote:

> As per previous posts, the -pbatard branch now has had the requirement for
> cdio_config.h (and cdio_unconfig.h) removed [1].
>

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.

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.



> With regards to its impact on the includes, I'm confident that the
> dependency for stdbool.h/HAVE_STDBOOL_H should be pretty much squared off
> (it's very straightforward to duplicate, and the 
> '__bool_true_false_are_**defined'
> guard seems universal), as well as the ones for HAVE_S_ISSOCK &
> HAVE_S_ISLNK --especially with the later commits that create a new
> filemode.h in lib/driver and remove the need for S_ISSOCK & S_ISLNK in the
> API altogether.
>
> With regards to stdint.h/HAVE_STDINT_H, I've also followed through with
> expecting it to be available by default, except on the few platform(s) we
> specify. Most platforms I know should be able to locate an stdint.h if
> missing, so even if it is not available by default, I do not see it as that
> penalizing for libcdio users.
>
> The next concern then is with sys/types.h and unistd.h. Basically, these
> seem to be required for the following types to be defined, as required by
> the API:
> - mode_t
> - size_t
> - ssize_t
> - off_t
>
> Currently, I am not aware of any platform that we ought to support that
> shouldn't have sys/types.h, and all the sys/types.h I see appear to define
> all of the above (expect for MSVC, but this will be addressed separately).
>
> Therefore, the patch removes the unistd.h dependency altogether and
> currently expects sys/types.h to be available everywhere (see the new
> include/cdio/types.h [2]). However, since it's impossible to check every
> system out there and there's a real possibility that some really don't have
> sys/types.h (or use unistd.h instead), I added a very explicit comment to
> contact the mailing list if the include is not found, so that we can add
> special cases accordingly. Libcdio users cannot fail to see that comment if
> the compilation chokes on sys/types.h so we should be fairly safe there as
> well.
>
> The one last item that we have to deal with then is "inline", as currently
> used in bytesex###.h and utils.h. Unfortunately, inline is only guaranteed
> available for C++, and pure C is expected to be a mixed bag. At least if
> you use gcc with option -ansi (and without -fgnu89-inline) or MSVC in pure
> C, inline is not available. However __inline__ or __inline respectively,
> are available as replacement.
>
> Thus my proposal is to replace all the stray inline from these includes
> with CDIO_INLINE and add the following at the beginning of bytesex###.h and
> utils.h:
>
> #if !defined CDIO_INLINE
> #if defined(__cplusplus) || defined(inline)
> #define CDIO_INLINE inline
> #elif defined(__GNUC__)
> #define CDIO_INLINE __inline__
> #elif defined(_MSC_VER)
> #define CDIO_INLINE __inline
> #else
> #define CDIO_INLINE
> #endif
> #endif /* CDIO_INLINE */
>
> This has now been applied in the -pbatard branch [3].
>
> I think these changes should leave the API in better shape for the future,
> but since they may break existing applications, it might be worth bumping
> the CDIO_API_VERSION from include/cdio/cdio.h when merging these commits
> onto mainline.
>

Replacing stdbool and inline seems fine. However we should let folks test
this to see how it goes.



> Regards,
>
> /Pete
>
> [1] http://git.savannah.gnu.org/**gitweb/?p=libcdio.git;a=**commitdiff;h=*
> *c46611553df657ed4c6a2af840bf3c**84eeafb0ee<http://git.savannah.gnu.org/gitweb/?p=libcdio.git;a=commitdiff;h=c46611553df657ed4c6a2af840bf3c84eeafb0ee>
> [2] git.savannah.gnu.org/gitweb/?**p=libcdio.git;a=blob;f=**
> include/cdio/types.h;hb=**beb74e6f238eb3448ef0078b90e945**b2791faa22<http://git.savannah.gnu.org/gitweb/?p=libcdio.git;a=blob;f=include/cdio/types.h;hb=beb74e6f238eb3448ef0078b90e945b2791faa22>
> [3] http://git.savannah.gnu.org/**gitweb/?p=libcdio.git;a=**commitdiff;h=*
> *787f8caed3a713d2506e199932436e**49a32a3034<http://git.savannah.gnu.org/gitweb/?p=libcdio.git;a=commitdiff;h=787f8caed3a713d2506e199932436e49a32a3034>
>
>
>


reply via email to

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