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
