[Resolved in TDM 2.08] TDM and the boost library

[Tels]

This thread is for technical issues about boost, as well as discussion on which parts we actually need or could replace, or if we actually want/can to get rid of boost.

 

Here are a few starters:

 

The file game/ModMenu.cpp includes boost, but doesn't actually use it anywhere, so the patch below works:

 

Index: game/ModMenu.cpp
===================================================================
--- game/ModMenu.cpp	(revision 6346)
+++ game/ModMenu.cpp	(working copy)
@@ -22,7 +22,6 @@
static bool versioned = RegisterVersionedFile("$Id$");

#include <string>
-#include <boost/filesystem.hpp>

#include "ModMenu.h"
#include "Shop/Shop.h"
@@ -42,8 +41,6 @@
	_modTop(0)
{}

-namespace fs = boost::filesystem;
-
// Handle mainmenu commands
void CModMenu::HandleCommands(const idStr& cmd, idUserInterface* gui)
{

 

 

Some functions use boost-specific objects, but then just use them like regular strings. I guess it is easier to pass in arguments that way, but instead of casting the object to char inside the function, this could also well be done by the calling place. Here are a few examples:

• IniFile::ConstructFromFile
• IniFile::ExportToFile

These two above are the only places where boost is used in IniFile.

[Tels]

Speaking of cleanup: While looking for the boost includes, I noticed that we have quite a mess here. Some of the files include the lobraries from .cpp files, others include them from the .h files (which is the right place IMO).

 

That again makes it harder to follow the source and see what is done and where. That's a general issue, tho, and not only for the boost libraries. But I guess since these were added later, the inconsistencies here are greater than for includes that have been there from the dawn of time on

[SteveL]

This is a good time to be looking at our boost dependency. greebo recently helped us migrate from vc2010 to vc2103, so we have access to C++11 features to replace the boost ones.

[revelator]

Standard libraries are by definition messy because they are so complex, that said they do offer more control over what you want to accomplish in comparison with standard C.

A rather large chunk of boost functionality is allready availiable in C++11 but we might run into other snags if we start using this as some things have changed meaning in the newer standard libraries.

feks. null is a keyword in C++11 and not a NULL pointer (well tbh NULL was newer a pointer in C++ as NULL is defined as simply 0 and not like in C where its (*(void *)0), and there might be other stuff to take into account. Still we may be able to make our own functions to do what boost was doing in the few places where its actually used.

[Tels]

I guess that actually replacing boost 100% is tough, because it brings a few often-used features, and some of the "only used once" features are rather complex, like traversing a directory recursively. It's not that we couldn't replicate that, but doing so in a correct, cross-platform manner is certainly not something done in 5 minutes.

 

Btw, the patch in the first post actually works, so I guess we could apply that as the first baby step

 

Anyway, the biggest issue I see right now is the error in Linux:

 

dlopen '/home/te/games/tdm/gamex86.so' failed: /home/te/games/tdm/gamex86.so: undefined symbol: _ZN5boost10filesystem6detail9copy_fileERKNS0_4pathES4_NS1_11copy_optionEPNS_6system10error_codeE

 

It looks to me the boost include files where recently updated (a few days/weeks ago), but the .a files in linux/boost/lib/ are from August. Maybe this is the reason? (I freely admit I'm a bit confused on how to exactly tackle this problem).

[SteveL]

Anyway, the biggest issue I see right now is the error in Linux:

 

dlopen '/home/te/games/tdm/gamex86.so' failed: /home/te/games/tdm/gamex86.so: undefined symbol: _ZN5boost10filesystem6detail9copy_fileERKNS0_4pathES4_NS1_11copy_optionEPNS_6system10error_codeE

 

It looks to me the boost include files where recently updated (a few days/weeks ago), but the .a files in linux/boost/lib/ are from August. Maybe this is the reason? (I freely admit I'm a bit confused on how to exactly tackle this problem).

 

I have no idea, but I'll go ask someone who does..

[SteveL]

greebo has committed new static libraries for linux, but they are version-sensitive. If you are using an old os build, you might have to compile your own.

[revelator]

i saw a build script in the boost libraries for darkmod i think you can use that to update the builds, i used the batch file here to make versions compatible with 2013 and the bash build script seems to fill in the same function.

[Tels]

greebo has committed new static libraries for linux, but they are version-sensitive. If you are using an old os build, you might have to compile your own.

 

Is therer anywhere any documentation about this? How to compile static versions, how to update them etc?

[SteveL]

There's some info on the wiki, although nothing specifically for Linux+Boost. But it gives the options for windows and Mac OS, which might help with the settings.

 

For reference, here's the command I used to compile boost for msvc.

b2 toolset=msvc variant=release,debug link=static threading=multi runtime-link=static stage /boost/chrono /boost/date_time /boost/filesystem /boost/program_options /boost/regex /boost/system /boost/thread

[Tels]

Good news: the new libraries work on my system.

[revelator]

Cool m8

[bedhead]

Whats wrong with using boost?

*Serious question as I'm still new to programming.

[SteveL]

Whats wrong with using boost?

*Serious question as I'm still new to programming.

it's just that it requires extra compilation steps when you're first setting up a build for a new compiler or platform. It's an excellent library, and it was the testing ground for most of the new features that became standard in C++11. We're considering getting rid of it only because C++11 is now out, and switching to C++11 could make it easier for people wanting to compile TDM on any platform other than our core MSVC2013 because they won't have to build Boost. But greebo mentioned that C++11 was poorly supported on Mac OS last time he checked, so unless that's changed we probably won't switch soon.