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

[Pete Batard]

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

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.

Regards,

/Pete

[1] 
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=beb74e6f238eb3448ef0078b90e945b2791faa22
[3] 
http://git.savannah.gnu.org/gitweb/?p=libcdio.git;a=commitdiff;h=787f8caed3a713d2506e199932436e49a32a3034