[TRE-general] config
skaller
skaller at users.sourceforge.net
Mon Aug 28 23:09:46 EEST 2006
Is there an explanation of the awful config files used by TRE?
There are a lot of macros, many seem duplicated in two
files, some use defined/not defined protocol and others
use 0/1 protocol. In addition, there is some redundancy
so that some code checks one macro and some code checks
a different macro, for the same option.
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!) .. I cannot use
autoconf style configuration. My configurator is a universal
Python script .. and trying to sort out what means what
so as to emulate the config tests proved too much for my brain.
I ended up just disabling every option: eg no wide char
support, no I18n support, etc. (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).
The reason I ask is that the Felix project now has C compiler
build support -- previously we could not compile C code,
only C++ (leading to 3 days of agony fixing the TRE sources
so they lived in the C/C++ common subset, and in doing so
forking the project and making upgrading impossible).
We'd like to move to a model where we bundle the original
and current TRE source codes with the project untouched.
The problem is we still have to do the building and configuration
with our Python scripts (autoconf is not permitted).
Is there any chance of just one config file with orthogonal
options? Or is there a reason not?
Hmm .. well yes .. autoconf is the reason not I suppose ..
the way out is to set TRE_* macros from the autoconf
ones .. and then use the TRE_* macros exclusively.
The best way to do this to entirely get rid of the
autocrap stuff is to write a C program that actually
prints out the config file: eg:
#include <autocrap.h>
#if HAVE_WCHAR_T // autocrap macro name
#define TRE_SUPPORT_WCHAR 1
#else
#define TRE_SUPPORT_WCHAR 0
#endif
int main()
{
printf("#define TRE_SUPPORT_WCHAR %d\n," TRE_SUPPORT_WCHAR);
...
}
This way the actual configuration can still be calculated by
autocrap, but TRE is not dependent on it.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
More information about the TRE-general
mailing list