[TRE-general] minimal build

[skaller]

On Sun, 2006-05-21 at 08:28 +0300, Ville Laurikari wrote:
> On Sun, May 21, 2006 at 01:03:45PM +1000, skaller wrote:
> > I'm trying to do a minimal build of tre 0.7.2 (modified to C++).
> 
> Why not 0.7.3?

Because the code doesn't build properly on 64 bit machine yet,
and certainly not at all using a C++ compiler.

I also have 0.7.3, and it is installed as a C library.
However until Tre builds out of the box on all platforms
we support, I feel the need to build it *inside* Felix.

Felix doesn't support building C code, so I had to
either convert Tre to C++ or add C compiler support
to the build system. The latter is very hard and ugly.

The rationale was that all good C code should be compilable
as C++ anyhow :)

Just for an idea of the structure: Felix uses two kinds
of libraries: nice C/C++ libraries to have, such as
gmp, gsl, etc. If your platform doesn't have these,
well too bad. We provide bindings to them, but its
up to the client to install these libraries.

The other kind of libraries are CORE functionality
which we guarantee on all platforms.

I would like Tre to be of that class -- which basically
means the Felix system has to ensure it is installed.
The best way to do that is to actually include the
source code in the tarball and build it as part
of the core system.

> > This involves turning off all the options: no GNU, no I18n,
> > no multibyte etc (I want 100% pure ISO C++ so it compiles
> > on all platforms).
> 
> I don't see how turning these off helps you, other than slightly
> reducing the amount of code you need to deal with.

It removes dependence on libraries which may or may not
exist on various platforms. For example I have NO idea
how to link to enable gettext support on Linux.
You don't say .. and GNU documentation here is hopeless :)

On Cygwin you need -lintl. For Mingw I don't know.
I also don't know how much of this stuff will work
using Visual Studio 2003 for win32, or VS2005 for
win32 and for win64.

Felix has to know all about these things to make
code work. The user does NOT link '-lintl' manually,
Felix does it automagically .. so it has to be configured.
Which means writing configuration scripts.

Turning all these 'maybe/maybe not' options off
gets rid of most dependencies especially conditional
dependencies, and allows me to test the core TRE
system without worrying about rubbish like wchar_t,
which should never have been added to C in the first place.

I may actually ask if you'd support regexps with 
characters of type 'int32_t', meaning, UCS-4 encoded
unicode. If I have to standardise something more than
8 bit characters, it would be that. If I have to have
multi-byte encoding, then UTF-8. None of this stuff
needs any extra libraries.

If I want \W type of support, I'll ask for a good
way to make charsets .. never never NEVER crud from
system locales.

TRE has to do that for Posix compliance .. but Felix
doesn't need it's standard regexp to be posix compliant:
I prefer sanity :)

Anyhow step 1 is to build Tre, build a Felix binding,
and write some test applications using it.

> This warning is better fixed by a cast at the call site:
>  ret = tre_compile(preg, (const tre_char_t *)regex, n, cflags);

Ok, I do that, thanks!

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net