[Top][All Lists]

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

Re: [Libcdio-devel] autoheader in the global namespace

From: Robert William Fuller
Subject: Re: [Libcdio-devel] autoheader in the global namespace
Date: Mon, 15 Oct 2012 21:19:16 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4

It's working for me in cued.  I have this in my

@SED@ @SED_EXTENDED_RE_FLAG@ -e 's/^([ \t]*#[ \t]*define[ \t]+)/\1CUED_/' $(top_builddir)/config.h >>cued_config.h


On 10/15/2012 09:10 PM, Rocky Bernstein wrote:
This sed stuff I find arcane and tricky even if I wrote it. That said, I've
just committed the change you suggest. Thanks!

(Hope it I got it right and it doesn't break anything.)

On Sat, Oct 13, 2012 at 8:29 AM, Robert William Fuller<
address@hidden>  wrote:

Although actually, you need at least one space after the #define, so this
would be even better (that's the + character, right?):

@/bin/sed -r -e 's/^([ \t]*#[ \t]*define[ \t]+)/\1CDIO_/'

If there's a line break with " \", o well.  Sed isn't really equipped to
deal with that.


On 10/13/2012 08:22 AM, Robert William Fuller wrote:

This is very clever. I think I will use it in my own project which will
help me support libcdio<= 0.83. It's a shame that autotools won't put a
prefix on there for you. I think this would be better (allow for more
whitespace variation:)

@/bin/sed -r -e 's/^([ \t]*#[ \t]*define[ \t]*)/\1CDIO_/'

On 10/11/2012 08:11 PM, Rocky Bernstein wrote:

All #define's in cdio_config.h should start CDIO_. For example:

#define CDIO_PACKAGE "libcdio"

The transformation is done inside include/cdio/ For
the relevant portion expands in Makefile to:

@/bin/sed -r -e 's/^(#[ \t]*define) /\1 CDIO_/'

There is some adjustment for other kinds of "sed" options.

So most likely your sed isn't sed'ing on OSX.

On Thu, Oct 11, 2012 at 7:29 PM, Robert William Fuller<
address@hidden>  wrote:

  Recently, I re-tooled my project (cued) to use autotools. I started out
by doing the naive thing when it came to including my project's
Here is an excerpt from rip.c:

#include "config.h" // HAVE_CDIO_MMC_LL_CMDS_H
#include "unix.h"
#include "util.h"

#include<cdio/mmc.h>  // CDIO_MMC_READ_TYPE_ANY

This seemed to work fine. I proceeded to make my project compile under
Linux, Open Indiana (Solaris), and FreeBSD. So far so good. Then, I
to port to MacOS, not because I am particularly concerned about
it, but because I figured it was different enough from the other 3
platforms that something might break.

Consequently, when trying to build under MacOS, I was rewarded with this

gcc -DHAVE_CONFIG_H -I. -I../.. -I/opt/local/include
-I/opt/local/include -I/opt/local/include -I/opt/local/include
-I../../lib/cued -std=gnu99 -Wall -Wstrict-aliasing=3 -Wformat=2 -g -O2
-MT rip.o -MD -MP -MF .deps/rip.Tpo -c -o rip.o rip.c
In file included from /opt/local/include/cdio/types.****h:34,
from /opt/local/include/cdio/cdio.****h:35,
from rip.c:25:
/opt/local/include/cdio/cdio_****config.h:306:1: warning: "PACKAGE"
In file included from rip.c:20:
../../config.h:91:1: warning: this is the location of the previous
In file included from /opt/local/include/cdio/types.****h:34,
from /opt/local/include/cdio/cdio.****h:35,
from rip.c:25:
/opt/local/include/cdio/cdio_****config.h:309:1: warning:

Add a half dozen more of these warnings, and you get the gist.
there was a conflict between my project's config.h and libcdio's
Yet, the warning only showed up on MacOS, not any of the other

The reason it showed up on MacOS is that MacPorts installs header
files in
/opt/local rather than /usr/include. GCC treats system headers
than other headers. It ignores redefined macros if they are redefined by
system headers (i.e. in /usr/include). This is documented under the GCC
option "-isystem".

So PACKAGE_NAME was defined to be "libcdio" rather than "cued", the name
of my package. VERSION was defined to be "0.83" instead of "1.20".
This is
a somewhat insidious problem because I got NO warning on ANY platform
than MacOS.

Next, I searched this mailing list to see what I could learn. I think I
fixed my problem by switching to the following code (but maybe not, read

#include "config.h" // HAVE_CDIO_MMC_LL_CMDS_H
#define __CDIO_CONFIG_H__ // avoid conflicts with libcdio
#include "unix.h"
#include "util.h"

#include<cdio/mmc.h>  // CDIO_MMC_READ_TYPE_ANY

I am not totally satisfied with this solution. If every library that I
used included its config.h in the global namespace, I might end up with
something like this (assuming that other projects create config.h
guards which they generally do not:)

#include "config.h"
#define __CDIO_CONFIG_H__
#define __SNDFILE_CONFIG_H__
#define __CDDB_CONFIG_H__

MOREOVER, I am not sure that<cdio/types.h>  will always do the right
when I define __CDIO_CONFIG_H__ before including it. You might argue I
should have used the other proposed solution for these sorts of
which would look something like this:

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

#include "config.h"
#include "unix.h"
#include "util.h"

#include<cdio/mmc.h>  // CDIO_MMC_READ_TYPE_ANY

Note that I need to include my "config.h" before<cdio/mmc_ll_cmds.h>,
I am supposed to include the cdio headers before my "config.h". Also
I am
not convinced that cdio_unconfig.h won't remove some definitions that
included in the GCC specs for some platform or in the system header
for that platform. For example, cdio_unconfig.h undefines "const".

Now the general autotools lore seems to be that you should never include
config.h in a header file, but only in a .c file. This is generally
attributed to the lack of include guard. I think that is missing the
point. Here, I will argue that you should never include config.h in a
header file because of the global namespace pollution and the
potential for
silent conflicts that show up as bugs.

One path out of this conflict is to remove code such as this from

/* Need for HAVE_SYS_TYPES_H */

/* Some systems need this for off_t and ssize. */

However, things aren't so simple when it comes to<cdio/types.h>, which
seems to have a real need to include its config.h.

Another path out of this conflict would be to create yet another
file, perhaps named cdio_header_config.h that contains ONLY the macros
needed by the cdio headers, such as HAVE_SYS_TYPES_H and HAVE_STDINT_H.
Yet again, /usr/include/cdio/types.h complicates things because there is
so much that it needs.

So, I am stuck, but still thinking about the problem. Thoughts?


reply via email to

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