[bt-devel] Windows Build status

[Greg Hellings]

Ok, so here's the gist of what today found:

I moved the dirent.h from the SWORD src/ subdirectory into the sword/
include directory.  That issue was then solved.

I changed all of the references from strcasecmp to stricmp - including
the header from SWORD allows this to be cross-platform compatible for
other build platforms.  However, chatting on IRC with Osk|log (some
one of the XML experts), it was discovered that most of the uses of it
to check for OSIS tags are actually unnecessary, since XML tag names
are case sensitive anyway, and the one occurrence where it appears to
be checking module names should be Unicode aware (which
stricmp/strcasecmp isn't, apparently) and Troy says that there is a
mechanism to do that build into the SWBuf.  Something along the lines
of toUpper(SWBuf(myString)) should perform proper Unicode-aware case
conversions.  Anyway, the issue is resolved for now, that's just a
heads up that Troy pointed out.

Eeli submitted a fix that solved the {ctor} error, so that is now
fixed (although should probably be tested in other build environments
as well).

Eeli also thought he had fixed the other issue with the 'i' :
'Rendering::CTextRendering::KeyTreeItem *' differs in levels of
indirection from 'int' error, but his fix wasn't correct.  When I
looked at the code at that location, I noticed that i is actually the
index of a for() loop within which the error occurs, and the error
occurs when trying to declare a new variable named 'i'.  Somehow
gcc/g++ have managed to allow this, but it utterly confused Visual
Studio.  Changing the references on lines 239, 241, 249, 257 and 259
from 'i' to 'dummy' (someone can come up with a more mnemonic name,
I'm sure) allowed the compile to complete.

Then came the fun of wading through linking errors.  I was
approximately up to my eyeballs in them (around 5600 linker errors at
first).  To get rid of the first batch I had to successfully link
against the SWORD dll file - this was easier said than done, but
eventually was accomplished after deciding that trying to compile a
dll is just bad news all around and that a static library is, far and
above, the way to go.  If someone could tell me or teach me how to
make Bibletime able to properly see the SWORD dll file, I would be
willing to pursue that route again, but it is well beyond my ken.
After that and a few other means of whittling out problems, I still
run into 36 linker errors.  They can be summed up into one category:
redefined functions.  3 of those functions are defined in both
libsword and clucene (they are from dirent).  3 more are defined in
both msvcprtd and libcpmtd (related to locks and debugging).  The
remaining 30 are defined in both msvcprtd and chtmlexportrendering.obj
and are largely redefinitions of standard string manipulation stuff.

When it comes to linking in Windows I am as effective as a lame duck
is at walking.  I understand that things like the libsword and clucene
redefinition problems can be averted using DLLs, or so I'm told, but I
don't know thing 1 about how to build a DLL and link against it.  I am
starting to learn, though.  And now that I have so much of the work
ironed out, I'm going to start it again tomorrow, document it closely,
and see if it clears up any of the little things remaining.

--Greg

On Tue, Feb 24, 2009 at 4:53 PM, Greg Hellings <greg.hellings at gmail.com> wrote:
> Eeli,
>
> On Tue, Feb 24, 2009 at 4:17 PM, Eeli Kaikkonen
> <eekaikko at mail.student.oulu.fi> wrote:
>> Greg Hellings wrote:
>>
>>> Other, miscellaneous errors which only seem to appear in Visual Studio
>>> in only two places:
>>> 2>..\bibletime-svn\src\frontend\settingsdialogs\clanguagesettings.cpp(98)
>>> : error C3083: '{ctor}': the symbol to the left of a '::' must be a
>>> type
>>>
>>
>> Please test if this one works now with my fix in svn. I don't understand why
>> this was so and why it seems to work both ways. Maybe the code doesn't
>> really work now...
>
> As we discussed in #bibletime, this error was cleared up with your
> commit to SVN.
>
>>
>>> 2>..\bibletime-svn\src\frontend\cinfodisplay.cpp(239) : error C2040:
>>> 'i' : 'Rendering::CTextRendering::KeyTreeItem *' differs in levels of
>>> indirection from 'int'
>>> 2>..\bibletime-svn\src\frontend\cinfodisplay.cpp(246) : error C2440:
>>> '=' : cannot convert from 'Rendering::CTextRendering::KeyTreeItem *'
>>> to 'int'
>>> 2>        There is no context in which this conversion is possible
>>> 2>..\bibletime-svn\src\frontend\cinfodisplay.cpp(254) : error C2440:
>>> '=' : cannot convert from 'Rendering::CTextRendering::KeyTreeItem *'
>>> to 'int'
>>> 2>        There is no context in which this conversion is possible
>>>
>>
>> I can't see any other reason for this than the inner class KeyTreeItem which
>> is inside CTextRendering. I committed a fix for this, too.
>
> This is a slightly stickier issue - your commit didn't clear it up, as
> I said in IRC, but I did find the solution just minutes after you
> logged out.  If you look on line 234, you will see:
> for( int i......)
>
> Then on line 239, where the first error appears and again on lines
> 241, 249, 257 and 259 you see i referenced again.  However, the line
> on 239 looks to me like a variable declaration.  Likely gcc/g++ takes
> it as such and creates *another* variable with even narrower scope (or
> does something even more sinister, like change your loop counter), but
> Visual Studio is showing the proper response of producing an error
> message, although a slightly confusing one.  By changing all of those
> references from i to a new name, the file compiled cleanly.
>
> That leaves only the strcasecmp/stricmp and dirent.h to work out, and
> both of those appear to have a few options for very simple solutions.
>
>>
>> Probably I should have sent these small changes in this email and not
>> committed them yet without testing, but I was in a hurry and too tired to
>> think about that. I hope these work - otherwise I should revert them (though
>> they both seem to work anyways).
>
> I know some people have talked about using distributed version control
> for such things as us collaborating and making many changes just to
> get the system compiled on this cross-platform setting, while not
> wanting to be forced to e-mail changes back and forth or run every
> possible fix through SVN.  I'm willing to work with you to cooperate
> in using one of those for these tasks - I know it would help me keep
> track of having slightly different fixes for MinGW, Visual Studio and
> Mac.  I'm always willing to spend a day or two setting up a new
> technology that can save me having to do a 15 minute task manually. =)
>
> --Greg
>