Re: Trying to get Windows building CRM114

Gerrit E.G. Hobbelt wrote:
> Nico Kadel-Garcia wrote:
>> 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.
>>   
> ???
>
> Well, at least it helps you stay somewhat current regarding mainstream 
> compression technology.
> I'm not the only one using 7-zip; it compresses much better than any 
> of bzip/gzip/rar/zip and that's a BIG plus for me, both in storage and 
> transport terms - both on- and off-net.
>
> Ah well, can't make everybody happy, I guess.
Well, open source or not, it's not built into any common operating 
systems or system utilities. and the compression and bandwidth 
difference is.... quite modest. For a public utility, it's a turnoff 
right from the start. It also presents yet another security issue of 
another unfamiliar, unpopular utility on one's system, even if it is 
open sourced.

>> 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.)
>>   
> I don't exactly follow that last bit, sounds to me like a read-only 
> git repository then, right?
> Anyway, go ahead.
That's what I'm setting up for Bill for CRM114. I can put up a separate 
git repository for *your* material adjacent to it, but that wouldn't be 
as useful as your using a good source control system and submitting 
changes there.

>> 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
>>   
>
> Urrrrck. Well, that's definitely worth a *man* too, then. Two steps 
> away from shuffling punchcard decks.
>
> Oh, and how recent were these 'I want PCRE support' inquiries exactly? 
> At least none of those came through these mailing lists the last 1.5 
> years or I've missed something vital there.
>
I'm not the one who got asked: from discussion here, it's considerably 
harder than one might realize because the regexp syntax is distinct.

>> Sorry, pavuk? You mean http://pavuk.sourceforge.net/? Oh, my that is a
>> rather different project. What did you think of incorporating?
>>   
> Yep, that one. Not so much 'incorporating' as just looking at a piece 
> of code where multiple regex libs are supported (though not in a 
> 'build them all right now right here on this box' style). Just an 
> example where multiple re libs are supported anyway: one sourcefile, 
> conditional compilation and a ./configure script 'driving' it. Wrapper 
> functions a la crmregex.c.
>
>> 'Slow Food'? OK, we're diverging from what I was trying to do.
>>   
> Not as much as you'd think: TRE is, AFAIK, still the fastest kid on 
> the block when it comes to regex matching. Which I consider a pre over 
> all the other ones. (Unless, of course, when you are 'into' perl regex 
> specialties too a degree where I'd advise detox. Only then, PCRE might 
> be your thing.)
Heh. *I* am not such a strong imbiber of the Perl Kook-Aid.

>> 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.)
>>   
> It's on my list of 'things to check out'.
>
>> > 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.
>>   
> Dependency? Screenshots?
> Heck, the whole thing is dependencies: that's how you tell what is 
> used by what in MSVC. E.g. libTRE is used by the libcrm114 static lib 
> project, so libcrm114 is dependent on libTRE. Then the crm114 (the 
> executable) is dependent on the libcrm114 project as it's there were 
> you find all the non-main() source code.
>
> <ping!> Ah , idea!
>
> You are probably running into a dependency on OpenSSL or OpenEXR, due 
> to those being used in various tools that I have around crm114. Just 
> delete those and the bmp* and prof* test tools from the solution 
> (didn't clean that one up, did I :-(( )
OpenEXR is the big issue. Since I'm such a Complete N00b, I hesited 
before attacking the .sln and .vcproj files.

>> 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.)
>>   
> I can guess who that is. ;-))  Had an inquiry through Bill last year, 
> it got all quiet after he got my answer. Orang puti tuti.
>
>
>> 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.
>>   
> Nope, that's nothing to do with the crm114 binary / libcrm114 core. 
> That's other tooling that's related. Didn't clean up after myself all 
> that well there, I see some old trials of said stuff are still stuck 
> in there.
>
> Anything 'Open'-whatever can go, no problem. In the end, you should 
> have these projects:
Cool. If I can encourage something like git source control, I'd be 
thrilled to publish a repository from your code and tweak it as 
necessary and hand it off to you, and that would allow me to sync to any 
changes you make (and publish them to you in graceful fashion).

> crm114
> libcrm114
> Bill's vector tokenizer test app
> the cssutils, osbfutil, etc.: 4 of em which came with crm114
> libTRE
>
> anything else should be gone. (When MSVC complains about not being 
> able to load certain projects, that a definite hint. libTRE should be 
> loadable now, anything else that isn't should be deleted from the sln.)
>
>
>> And oh, my goodness. Are you really providing Microsoft's SP! packs at
>> http://hebbut.net/Public.Offerings/libTRE.html#Downloadable_archives_files? 
>>
>> [...]
>> as a clinical test of whether they were wearing their implant all the
>> time.]
>>   
> Heh, so I'm not the only kwei lau around, eh?
> Well, let's just say I've put those up for the folks that feel safe 
> about it. Or more, ah, entrepreneurial from your security perspective.
> Anyhow, what's on there doesn't /have/ to be downloaded. ;-)
> The links to Microsoft are provided as well, so with a few more 
> clicks, you're back in the comfort zone.
>
> It's saved me quite a few support hassles, so they will stay there.
I'd just publish a URL to Microsoft's download site. Even if I trust 
*your* code, especially after review, installing binary service packs 
from someone other than the vendor... well, at my last workplace, it 
would have gotten me fired, for violating policies I wrote.


>> And oh, my goodness. Are you really providing Microsoft's SP! packs at
>
> And, just this once, *READ* what it says there on the website. It's 
> NOT Windows Service Packs.
> When you want to be anal, better make damn sure you stick it up the 
> correct hole, all right?
> I'll put those bleeding gums down on too much development effort, 
> combined with too little sleep. Happens to me.
>
> Cheers.
>
I've read it. I didn't say 'Windows'  I said 'Microsoft'. I admit to 
being sloppy about what is Windows and what is Visual Studio: I'd 
consider a vendor's designated compiler part of the OS, even if they 
sell it as a separte product. But I'll try to keep your gums from 
bleeding by being more cautious about the langage.

Have a good night.....

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