[Top][All Lists]

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

[Libcdio-devel] Duplicate C Preprocessor header includes (Was Re: libcdi

From: Rocky Bernstein
Subject: [Libcdio-devel] Duplicate C Preprocessor header includes (Was Re: libcdio 0.83 release around Oct 27, FreeBSD-8 test)
Date: Thu, 20 Oct 2011 21:06:06 -0400

To sum up the situation and the solution that is now in git...

libcdio install <cdio/cdio_config.h>; it contains all of the C Preprocessor
values from config.h (created by configure).

This header can be used to consult exactly how libcdio was built. Initially
I had selected "interesting" values, but this became too hard to maintain.

One set of values that libdio needs internally is the BigEndian/LittleEndian
and it can get this from config.h or cdio_config.h. The former of course is

Some of the libcdio programs like the demo programs include config.h for the
usual reasons, e.g. do we have <unistd.h>?

And then the program would want to include <cdio.h> to get libcdio headers
because libcdio needs some of the same information like BigEndian value we
have a duplicate include.

The way I have changed libcdio to get around this, and applications using
libcdio should do the same is to use:

# include "config.h"
# define __CDIO_CONFIG_H__ 1

Defining  __CDIO_CONFIG_H__ will make sure config_cdio.h doesn't try to
redefine preprocessor symbols.

Ok. But now what about the problem that there are common preprocessor
symbols in config_cdio.h that an application may want to define in a
different manner, like PACKAGE_NAME?

For this I've justed added yet another header, <cdio/cdio_unconfig.h> file
which will undefine any symbol that config.h defines. And now we bounce to
the problem that there may be symbols that are normally defined
(HAVE_UNISTD_H)  and you want to keep that way, but others that you don't.
So here is what I suggest

   // for cdio:
   #include <cdio.h>
   #include <cdio_unconfig.h> # remove *all* symbols libcdio defines

   // Add back in the ones you want your program
   #include <config.h>

The solution isn't the most simple or natural, but programming sometimes can
be difficult. If someone has a better solution, let me know.

Between cdio_config.h and cdio_unconfig.h and all the fact that almost all
headers** define a symbol to indicate they have been included, I think there
is enough mechanism to cover any situation that may arise.

** <cdio_unconfig.h> is one of the few headers that doesn't set a
preprocessor symbol: it does its thing every time it is #included

On Thu, Oct 20, 2011 at 6:02 PM, Thomas Schmitt <address@hidden> wrote:

> Hi,
> i now built GNU xorriso with --enable-libcdio on FreeBSD 8.0-STABLE.
> It might be that the use of cdio_config.h is not compatible with the own
> autotools setup of applications which use libcdio:
>  In file included from /usr/local/include/cdio/types.h:34,
>                   from /usr/local/include/cdio/cdio.h:35,
>                   from libburn/sg-libcdio.c:145,
>                   from libburn/sg.c:21:
>  /usr/local/include/cdio/cdio_config.h:297:1: warning: "PACKAGE" redefined
>  In file included from libburn/sg.c:9:
>  libburn/../config.h:101:1: warning: this is the location of the previous
> definition
> xorriso does not make use of these macros. But it is not healthy
> that the libcdio config macros get included into the application.
> Have a nice day :)
> Thomas

reply via email to

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