[TRE-general] config
Ville Laurikari
ville at laurikari.net
Wed Aug 30 15:19:37 EEST 2006
On Tue, Aug 29, 2006 at 06:09:46AM +1000, skaller wrote:
> Is there an explanation of the awful config files used by TRE?
I don't like it myself either. I've been thinking about getting rid
of GNU autoconf, automake, and libtool. If I get enough motivation
someday I might even do something about it.
> There are a lot of macros, many seem duplicated in two
> files
There are indeed two files with overlapping #defines. The reason is
that the other file, `config.h', is used when compiling TRE. It
contains all #defines, and it is automatically generated from
`configure.ac' by the GNU autoheader tool.
The other file, `tre-config.h', is used when TRE is installed with
`make install'. We don't install `config.h' because the #defines
there may overlap and contradict the #defines from whatever is
including the TRE headers. That is, if you #include <tre/regex.h> you
might end up with all sorts of extra stuff #defined. That's why there
is the stripped down `tre-config.h'.
This is partially explained in the beginning of `tre-config.h'.
I haven't figured out a simple way to make those two files
non-overlapping. Autoheader wants to put everything it finds in
`config.h'.
> some use defined/not defined protocol and others
> use 0/1 protocol.
In autoconf world, a macro is either undefined or defined to 1. This
means that both
#if FOO
and
#ifdef FOO
work. There may be some inconsistency in the codebase as to whether
#if or #ifdef is used.
> Is there some POSIX or GNU reason for this mess?
>
> Because I build Tre on many platforms .. including on
> Windows using MSVC++ (yes, it works fine!)
It works fine also with the win32/tre.dsp project file ;)
> Python script .. and trying to sort out what means what
> so as to emulate the config tests proved too much for my brain.
The comments in `config.h' should provide enough clues about what each
macro means.
It can be confusing, though. There are separate macros for the header
files (e.g. HAVE_WCHAR_H), the types (e.g. HAVE_WCHAR_T), and whether
we want a feature included (e.g. TRE_WCHAR). Still, the macros are
orthogonal so that even though you have wchar.h and wchar_t you may
still want to turn wchar support off. Or you may not have wchar.h,
but still have wchar_t, and vice versa. Of course, if you don't have
wchar_t then TRE_WCHAR will be undefined.
This is the Autoconf way. You define a macro for header files which
may or may not be present, and types, and functions, and some other
things. If you want to explicitly turn features on and off, you add
another macro for that.
I don't like it, but that's how Autoconf is supposed to be used.
> (It's also very hard to link stuff like gettext, since its in
> different places on say Linux to Cygwin .. and probably not
> available on Win32).
Autoconf scripts handle this by implementing a program which searches
for gettext in the usual places (libc and some libraries). Another
option is to keep a database for each supported operating system about
what libraries you need and where they may be.
> Is there any chance of just one config file with orthogonal
> options? Or is there a reason not?
config.h is close. The options are mostly orthogonal, but some
combinations do not make sense.
--
http://www.iki.fi/vl/
More information about the TRE-general
mailing list