[Libcdio-devel] HAVE_CONFIG_H vs EXTERNAL_LIBCDIO_CONFIG_H

[Pete Batard]

The first hurdle we meet for MSVC support has to do with the above, and 
the apparent lack of harmonization between using a (topdir)/config.h or 
a cdio/cdio_config.h.

As a matter of fact, one of the first thing the make process has to do 
is duplicate the toplevel config.h into include/cdio/cdio_config.h, 
because the current libcdio compilation process very much seems to 
require both.

For instance, cdio/types.h has only:

#ifndef EXTERNAL_LIBCDIO_CONFIG_H
#define EXTERNAL_LIBCDIO_CONFIG_H
#include <cdio/cdio_config.h>
#endif

Which means only cdio/config.h can be used there, whereas 
lib/udf/udf_fs.c has only:

#ifdef HAVE_CONFIG_H
#include "config.h"
#define __CDIO_CONFIG_H__ 1
#endif

Now, I can understand the rationale for giving the choice between using 
either a toplevel config.h or an "external" cdio_config.h, but in this 
case, shouldn't all files provide an exclusive choice between including 
one or the other? In other words, shouldn't we have all our config 
dependent files starting with:

#if defined(HAVE_CONFIG_H) && !defined(__CDIO_CONFIG_H__)
#define __CDIO_CONFIG_H__ 1
#include "config.h"
#else
#if !defined(EXTERNAL_LIBCDIO_CONFIG_H)
#define EXTERNAL_LIBCDIO_CONFIG_H
#include <cdio/cdio_config.h>
#endif
#endif

As a matter of fact, this is precisely how I modified all the sources 
that I integrated for MSVC support in my app, and I'm planning to do the 
same to add MSVC support in -pbatard. However, because the current 
libcdio seems to completely ignore this issue, I can't help wondering if 
I'm missing something...
Is there any rationale for what looks like a very messy state of config 
support?

Regards,

/Pete