[bt-devel] Windows Build status
Martin Gruner
mg.pub at gmx.net
Tue Feb 24 11:31:13 MST 2009
Hello all.
@Greg: thanks for all your input. We'll try to include your proposed changes
as soon as we can. Keep it coming.
(We might end up with a MinGW build chain, however, instead of VS. It would
allow us to have one common build process controlled by cmake.)
@Eeli: I'm leaving this thread to you for now. I probably won't have time this
entire week and need to get a windows environment set up as well.
Maybe you can use the development planning page to track the platform
compatibility items, so that we do not loose control.
@Gary: Please contine to complete the port, adding missing functionality, if
you have time. Let others do the dirty windows work. ;)
Regarding planning: My suggestion would be to concentrate on bugfixes and
improvements for platform compatibility now. I'd like to release a 1.8.beta1
version sometime next week, if possible. For 1.8, I believe we do not have to
offer a complete windows build yet. But a foundation that people can start to
work / port from.
Ok?
mg
On Tuesday 24 February 2009 09:10:36 Eeli Kaikkonen 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?
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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
>
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
More information about the bt-devel
mailing list