Re: Trying to get Windows building CRM114

On Thu, Mar 5, 2009 at 11:12 AM, Ger Hobbelt <[email protected]> wrote:
> 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 :-( )

OK, it seems helpful, but *man*. Why, oh why, do you start out with
TRE tools compressed in this '.7z' format? Making someone install an
add-on utility to access it seems painful.

We've gotten Bill to agree to git support for CRM114, and are merely
awaiting his buy-in to make the current development code available on
Sourceforge via git. This will let people download development code
and do their own development in their own repositories, and either
submit changes by publishing their own repository and allowing him to
merge from their repositories, or publishing diffs from them.

Can I set this up for you? I've got a crm114-hebbut git repository,
with your old releases in it as tags. I could push it to the
sourceforge site when that's active, with your buy-in, or hand it to
to you for you to use. I can't, unfortunately, put that on sourceforge
with you to have write access and restrict the git repository there to
give Bill the limited access he'd ideally like, lest developers
accidentally step on the master. (And accidents are a problem,
especially with a new system like this.)

> 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.

That's the conclusion I'm reaching. There isn''t any demand that I'm
aware of to use GNU regexp: some folks have apparently asked for PCRE.
I'm trying to get something like your already existing Windows
compilation work into what is effectively the old fork.

>> 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.

'dovy'? Hmm.

Bill didn't have this problem in his original work environment and his
original Makefile's, because he'd edit the crm114_sysincludes.h and
build the crm114_gnu, and actually overwrite the local crm file. It's
the attempt to resolve these and make them much more automated and
autoconf compatible that introduces the need to be consistent in our
build structures.

This is a classic problem when moving from old, developer style code
to more project style project-level build environments. Bill is buying
into this: I'm taking advantage of his buy-in to push as far as I
reasonably can. I'm trying to get the git release of code, and then
get a new autoconf style release if I can get his full buy-in for it.

> 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:

Sorry, pavuk? You mean http://pavuk.sourceforge.net/? Oh, my that is a
rather different project. What did you think of incorporating?

> 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. ;-) )

'Slow Food'? OK, we're diverging from what I was trying to do.

> 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.

I  personally agree completely with this. In fact, I personally think
that CRM114 should be bonded completely to TRE. Supporting multiple
regexp libraries introduces support costs that aren't worth it unless
there is some features set that is really, really worth it. I want to
dump GNU regexp entirely, since no one seems to be using it, in fact.

> 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.

Ger, can I introduce you to 'git' source control? I've fallen in love
with it these past two months. It really solves a lot of Subversion's
flaws, and should be takenn up immediately for security reasons alone.
(Subversion replicated CVS's security flaws by writing user passwords
in plaintext in .subversrion/* configuration files, which I consider
inexcusable.)

> 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.

I'm looking at this. I am a *complete* n00b at Visual Studio, but why
do you have this dependency in your .sln files for CRM114? I run
headlong into this dependency in attempting to build your fork.

> (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.  ;-) )

Well, yes. I have a client with a desire to have CRM114 work in
Windows, in a situation Bill is aware of and which I'm trying to work
with him to satisfy. (I'm trying to be cautious of the client's
confidentiality desires, so don't feel free to be completely open
about the client.)

The OpenEXR requirement to build your stuff seems, at first glance, to
be excessive. Is that crm114.sln just unnecessary, for example? I'm
operating in a CygWin environment to provide git access and source
control to this, which is why I built a crm114-hebbut repository.

And oh, my goodness. Are you really providing Microsoft's SP! packs at
http://hebbut.net/Public.Offerings/libTRE.html#Downloadable_archives_files?
Can I seriously discourage you from doing that? It presents a serious,
serious security problem for me to even *think* about grabbing
Microsoft security packs from a third party. While you may be a
wonderful guy with a reasonably secure web server, the very concept of
grabbing fundamental OS service packs from your website makes my gums
bleed to think about.

[Yes, I do have a taste for colorful metaphors: it used to be possible
to tell when cochlear implant subjects I used to work with directly
were getting full benefit from their devices because they'd look at me
and say "what the heck did you just say"? We could actually use that
as a clinical test of whether they were wearing their implant all the
time.]

------------------------------------------------------------------------------
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