Re: Trying to get Windows building CRM114

VS2005SP1

See also the description at hebbut.net's crm114 page (I notices I
crapped up there: old copy&paste text snippet was there which has been
updated along the lines of the OpenEXR page. Hm, should make a
separate page where project layout and policy is described, as that
bit is rather spotty to non-existent on there :-( )


On Thu, Mar 5, 2009 at 2:39 PM, Nico Kadel-Garcia <[email protected]> wrote:
> Ger, I'm trying to get Visual Studio 2005 to build your source tree, and
> having issues with it. Remind me what Visual Stuido you used? And did you
> have to do any special setup steps? And did you incorporate TRE to your
> system, or did you rely on the Posix or GNU regexp?

Always build with TRE. Did use gnu regexp for a while, but that is
loooooooooong time ago. Shouldn't find any rudiment of that anymore in
the project files anyway.


> I'm also looking at that "build a GNU regexp binary with a different source
> file", and that just makes me twitch for various reasons. I'm looking at
> 'have one crmregex.c file, and use "#ifdef REGEX_GNU" or "#ifdef REGEX_TRE"
> ' to avoid the building of all the other files with one regex.h selected in
> crm114_sysincludes.h, and only the crmregex_gnu.c uses a different one. That
> way lies.... including two different regex.h files for different parts of
> the same software, and that way lies madness.

And not to mention all those lovely dovy regexp libs all share the
same 'assumed to be there in system dir' <regex.h>, which, of course,
will result in serious collisions if you try to build/test such a
thing on a single machine.
Check out how pavuk handles this; it uses that #if defined ...  #elif
defined ...  approach you mention and stays the hell away from all the
extra goodies some of those libs offer for enhanced capabilities or
speedup (TRE for one). I intended to incorporate that into crm114 as
an aside but things kept me from completing it ever:

1) crm114 script requires subexpression handling, which not all of
them have on offer.
2) crm114 script has enough portability issues as it comes (path
separators and // delims clash, for instance; the whole syscall
business is another) and adding 'do we write our regexes the perl, the
awk, the sed, or the whatchamahavetoday style' conundrum to it wasn't
on my list of Happy Thoughts.
3) making crm114 'happen' for me took enough effort in other areas
(internal: parser, etc., external: test rig setup, getting to grips
with the classifiers, etc.) without this 'aside'.
4) tests using pavuk and a few private tools, led me to the conclusion
that TRE was the fastest of the bunch anyway and I am not exactly
looking for extra slowdown in my setup here.
(I'm aware of the Slow Food movement. Kinda like it. Doesn't mean I
like Slow Software. ;-) )


My advise: unless you have some serious itch regarding the desire to
introduce regex incompatibilities across crm114 builds across the
world, just because they happen to find (and use) a different regex
lib on thier box, you'd better enforce a strict bond to TRE.
In case you wonder, here's an easy starter: check out how each of
those regexp libs treat the various inputs and what it takes to make
characters 'active', i.e. as a regexp element instead of a literal: to
\-escape or not to \-escape, that's the question. \{ vs {, [ vs \[, \(
vs ( , etc.etc. Do we support \w today, or don't we? Do we support {}?
Then there's the little setback regarding [:...:] sets: as not every C
RTL (Windows again!) has all the is...() macros, you may find that
your regexp lib suddenly doesn't support all the [:...:] it did on the
other box right there. (This also applies to TRE. See the patched TRE
at hebbut.net.)
My conclusion: best is to stick with one (TRE), and stick with it _hard_.

The fact that my ./configure still tried to detect all those regexp
libs until very recently, despite the above already a forlorn
conclusion, has been giving me nothing but support trouble.
Multi-regex detect code? Ditched.
There's special TRE code in ./configure to make sure the TRE headers
are loaded so you get all the TRE goodies and not just the TRE
compatibility layer.




PS: when building the MSVC projects, you might run into a few 'tools'
or 'test' projects missing. Remove those from the solution and you
should be good to go. IIRC, I didn't apply CreateDLL to libTRE (DLL
project) and if I did, it's part of OpenEXR, which is also available
at hebbut.net.
(CreateDLL removes the need to apply dllexport/dllimport (or .DEF
files, eeek!) to Win32/64 DLL code, which makes the code all the more
cross-platform portable. Too bad I haven't thought of building that
tool myself; it's part of OpenEXR. In case you're considering giving
libcrm114 a DLL / .so workover.  ;-) )


-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
        http://www.hebbut.net/
mail:   [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H