[bt-devel] Windows (again)

Eeli Kaikkonen eekaikko at mail.student.oulu.fi
Sun Mar 1 14:15:08 MST 2009


Greg Hellings wrote:
> Eeli,
> 
> 1) Your changes to FindSword.cmake work exactly as needed to provide
> me with the GUI interface I need to configure.  You can commit that
> file so long as it works for you under Linux too.
> 

Ok, I'll commit it.

> 2) The conditional compile flags don't seem to have taken hold.  I
> still had to remove the -Wall -O0, etc.
> 

It may be caused by a wrong condition variable. I can't check what 
variables your system sets. You can look at it in the cmake man page and 
change it yourself if you want to. In particular, I didn't use WIN32 
because this issue depends on the compiler, not OS.

> 3) bibletime_dbus_adaptor.cpp and bibletime_dbus are still included in
> the sources under Windows, but it really shouldn't be.  It might not
> make a difference in the end, since they compile cleanly, but since
> DBus doesn't exist on Windows, they should probably be taken out.
> Maybe just keep a list of the main sources and then detect if we're on
> a DBus system then add in the dbus-specific files?
> 

Removing it altogether may be a "cleaner" way to do it. I used #ifndef 
which works well  - it makes the bibletime_dbus_adaptor.cpp file empty 
if DBus isn't used - and shows occasional reader of c++ code that it 
won't necessarily be compiled. bibletime_dbus must be and is compiled 
anyways, it has normal functions. I'll keep it this way unless someone 
persuades to do otherwise.

> 4) Could it be possible to modify the .SVG files directly to .PNG
> files at installation time, through adding just a quick line to the
> CMake files to execute inkscape if the system detects WIN32 and
> convert the files before installation?

Yes, it's possible. We can try to detect inkscape and do the conversion 
if it's found. If it's not found we can print a message stating that SVG 
files may not work on Windows. Let's consider this for a while.

> 5) I'm doing a fresh, clean build so that I can have it prepared to
> zip up for other developers to use to build on their systems as well.
> Being that it includes the boost headers, it looks like it's going to
> be a large ZIP file, but hopefully it won't be too unwieldy.
> 

If it's true that we need only the headers we could put them alone in 
the package. Is it too much work to separate them from the distribution? 
http://www.boost.org/doc/libs/1_38_0/more/getting_started/windows.html 
says this:

This is a sketch of the resulting directory structure:

boost_1_38_0\ .................The “boost root directory”
    index.htm .........A copy of www.boost.org starts here
    boost\ .........................All Boost Header files
    lib\ .....................precompiled library binaries
[...etc.]

So, we would need only boost_xxx\boost\. It's only 60M unpacked or < 5M 
packed while the whole package is 260M unpacked or ~30M packed.

BTW, we use only boost/scoped_ptr.h. It's used for safety and easiness, 
not for functionality. It could be replaced with manual memory handling.

> 6) There is still one place in cswordmoduleinfo.cpp on line 240 where
> you need to cast stop_words to (const TCHAR**) === note that it is
> properly a pointer-pointer type.  That looks like it should be the
> only actual coding problem still remaining with Visual Studio 2008
> compilation.
> 

I'll change it. If you can make it work like Gary proposed, we can 
easily change all occurrences back.


--Eeli Kaikkonen



More information about the bt-devel mailing list