[bt-devel] Windows Build status

[Greg Hellings]

On Tue, Feb 24, 2009 at 2:10 AM, Eeli Kaikkonen
<eekaikko at mail.student.oulu.fi> wrote:
> Quoting Greg Hellings <greg.hellings at gmail.com>:
>
>> So the Windows building was, not surprisingly yet disappointingly, not
>> nearly as smooth as the Mac build.  I have built Qt 4.4.3 for both
>> Visual Studio and MinGW tool chains.  Likewise I have built CLucene
>> for both tool chains.  SWORD also builds on both systems once you
>> either put together a basic MinGW/MSYS system (I used some of the
>> directions from the wiki on how to build Xiphos on Windows, but I took
>> great liberties and really only went so far as to install the
>> libraries that he suggested - I did install the Technology Preview
>> versions and they seem to work just great).
>
> We should somehow make this as easy as possible for newcomers. Maybe a zip
> package which includes all the tool and library packages?

It's probably better to setup a wiki page like the Gnomesword team did
and document exactly what to do and how to do it - I know it would be
a nightmare for me to think of exactly what I did more than a few days
into the future.  Perhaps tomorrow I'll see about getting it down in
writing.

>
>>  I am sure I could build
>> ICU under Visual Studio as well, since that is an officially supported
>> system for them (and there are also .dll files that someone else in
>> the SWORD project world has either acquired or built themselves that
>> could be used).
>
> It's still not clear to me how icu is used in SWORD.

Me, neither - the library builds fine without it both under Mac and
Windows, but BibleTime seems to assume that it's there when I was
linking it on Mac and getting lots of undefined reference errors.
Making sure it was linked into the SWORD library, though, gets rid of
them all on the Mac.  Once I'm to the linking stage on PC I'll be able
to re-look at it from the PC perspective.

>
>> Using CMake I was able to configure BibleTime for use
>> with Visual Studio 2008, since I find that programs built with the
>> native compiler tend to be much better at their jobs than those built
>> with a compiler that's been shoe-horned into the system.
>
> It may be better to build the binary releases with a native compiler, but
> for open source developers it's important to have a free toolchain for
> development.

True - there was a large collection of CLucene errors when I was
building in MinGW/MSYS, so I went to the Microsoft tools, since I was
hoping to get it working in there.  Having it build with both is
important for developers, but for releasing to users VS is probably
better.

>
>> The
>> following errors manifest themselves:
>>
>> strcasecmp - the case agnostic string comparison function is called
>> stricmp on Windows.  Change the name and it works marvelously
>> (probably a simple #define macro could work perfectly, even in
>> config.h.cmake).
>
> Yes.

Or the methods that Chris pointed to in his e-mail.  I just changed
the names to stricmp and compiled and it worked - so I don't know if
its picking up the native implementation or the SWORD one.

>
>> pthread.h - no such file in Visual Studio 2008, although there is an
>> open source implementation of pthread-win32, its latest release is
>> 2006 and I haven't tried to build it in Visual Studio.  Qt3 had the
>> option of no threading - so it made sense to use pthread back then,
>> when there may not have been support in Qt.  However, according to
>> Trolltech's Qt4 Thread page, it is always enabled in Qt4, so it might
>> be a smart idea to move to using Qt-only for threads.  pthread.h does
>> exist for MSYS/MinGW, though, so that is a possibility.
>
> You didn't say where this is. Is it really in BT code? We shouldn't be using
> it.

cswordmodulesearch.h includes it which causes the error to appear
about 10 times when that header is included in other C++ files.  That
is the only file that I see, but I may have glossed over one.  When I
comment it out, all the files that depend on csworemodulesearch.h
compile except for cswordmoduleinfo.cpp which produces the following
errors:

1>..\bibletime-svn\src\backend\drivers\cswordmoduleinfo.cpp(309) :
error C2664: 'lucene::document::Field::UnIndexed' : cannot convert
parameter 2 from 'wchar_t [1048577]' to 'const TCHAR *'
1>        Types pointed to are unrelated; conversion requires
reinterpret_cast, C-style cast or function-style cast
1>..\bibletime-svn\src\backend\drivers\cswordmoduleinfo.cpp(315) :
error C2664: 'lucene::document::Field::UnStored' : cannot convert
parameter 2 from 'wchar_t [1048577]' to 'const TCHAR *'
1>        Types pointed to are unrelated; conversion requires
reinterpret_cast, C-style cast or function-style cast
1>..\bibletime-svn\src\backend\drivers\cswordmoduleinfo.cpp(326) :
error C2664: 'lucene::document::Field::UnStored' : cannot convert
parameter 2 from 'wchar_t [1048577]' to 'const TCHAR *'
1>        Types pointed to are unrelated; conversion requires
reinterpret_cast, C-style cast or function-style cast
1>..\bibletime-svn\src\backend\drivers\cswordmoduleinfo.cpp(334) :
error C2664: 'lucene::document::Field::UnStored' : cannot convert
parameter 2 from 'wchar_t [1048577]' to 'const TCHAR *'
1>        Types pointed to are unrelated; conversion requires
reinterpret_cast, C-style cast or function-style cast
1>..\bibletime-svn\src\backend\drivers\cswordmoduleinfo.cpp(344) :
error C2664: 'lucene::document::Field::UnStored' : cannot convert
parameter 2 from 'wchar_t [1048577]' to 'const TCHAR *'
1>        Types pointed to are unrelated; conversion requires
reinterpret_cast, C-style cast or function-style cast
1>..\bibletime-svn\src\backend\drivers\cswordmoduleinfo.cpp(349) :
error C2664: 'lucene::document::Field::UnStored' : cannot convert
parameter 2 from 'wchar_t [1048577]' to 'const TCHAR *'
1>        Types pointed to are unrelated; conversion requires
reinterpret_cast, C-style cast or function-style cast
1>..\bibletime-svn\src\backend\drivers\cswordmoduleinfo.cpp(425) :
error C2665: 'lucene::queryParser::QueryParser::parse' : none of the 3
overloads could convert all the argument types
1>        c:\users\greg\desktop\build\include\CLucene/queryParser/QueryParser.h(89):
could be 'lucene::search::Query
*lucene::queryParser::QueryParser::parse(const TCHAR *,const TCHAR
*,lucene::analysis::Analyzer *)'
1>        while trying to match the argument list '(wchar_t [1048577],
const char [8], lucene::analysis::standard::StandardAnalyzer *)'
1>..\bibletime-svn\src\backend\drivers\cswordmoduleinfo.cpp(438) :
error C2664: 'lucene_wcstoutf8' : cannot convert parameter 2 from
'const TCHAR *' to 'const wchar_t *'
1>        Types pointed to are unrelated; conversion requires
reinterpret_cast, C-style cast or function-style cast

By doing exactly what it says I was able to eliminate those errors.
That reminded me that the same type of errors had been appearing on my
attempt to build with MinGW.  So I patched the file so that there are
no more errors in either Visual Studio or in MinGW.  However, the file
still fails to build in MinGW because of errors in the CLucene headers
related to the const TCHAR* problems.  I can provide those errors, but
it's not that important.  Attached is a patch for the file to make it
compile under VS.  Please check to see it still works on other
systems.


>
>> dirent.h - there is also no such file in Visual Studio, though there
>> is in MinGW.  Just glancing through the Qt4 documentations, use of the
>> QDir object would allow the same functionality that is being used in
>> CSwordBackend::moduleConfig.  As in the case of pthread, it's probably
>> desirable to move to using all native Qt functions rather than
>> non-Standard  system headers like dirent.h.  But I don't think that I
>> quite grasp the exact functionality at this hour, so I will refrain
>> from trying to submit a patch for that.
>
> I have noticed that earlier. Yes, we should bet rid of that, though I think
> it's available for Windows, see http://en.wikipedia.org/wiki/Dirent.h.

Obviously either would be feasible, though probably using Qt would be
more robust and would allow us to leverage their fixing of bugs
without having to track Yet Another Externally Imported Library.

>
>
>> BT_VERSION - this is normally defined in config.h, but it doesn't
>> appear to have been in the version of config.h which was included to
>> its references in the source in main.cpp, migrationutil.cpp and
>> bibletime.cpp.  I manually moved the bibletime-svn/src and
>> bibletime-build/ include lines to the top of Visual Studio's include
>> lists for the include search, and this error went away.  I presume VS
>> was pulling in a config.h from Qt or something like that.
>>
>
> We could rename our file to bt_configuration.h, there should be no problem
> in that.

config.h makes more sense - it's more in keeping with other software
I've seen - and the issue is just an ordering of the include
directories.  Obviously it's a quirk of CMake, since the problem
doesn't appear in Mac or Linux.  I'd say leave it be and we can just
shuffle it around when we make the project file in VS.

>
>> 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
>>
>> 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
>
> We have to fix these. They are probably minor things.
>
>>
>> So, while I have a built and ready-to-go version of Bibletime on my
>> Mac that I was happily using today, Bibletime on Windows is slightly
>> further out, though not insurmountably so.  The goal is within
>> eyesight!
>>
>
> Now I really hope I had time today, but I don't.
>
> --Eeli Kaikkonen

I'm afraid I'll be in the same situation when I wake up tomorrow. But
hopefully someone can clear up just those 4 real issues:
pthread/lucene, dirent and the two typing issues and I should have
time to try building the system again tomorrow evening if those issues
can get sorted.

In other news, there are also some errors when compiling the whole
system with the howtos, because they are looking for xsltproc, which
is not a part of my Windows (though I have a version installed in
Cygwin).  I put Cygwin in my path and set my CYGROOT accordingly, but
now it still dies, complaining of a missing po4a.  Are any of those
actually necessary for the build?

--Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cswordmoduleinfo.patch
Type: application/octet-stream
Size: 3713 bytes
Desc: not available
URL: <http://www.crosswire.org/pipermail/bt-devel/attachments/20090224/6e07a9f4/attachment-0001.obj>