Jump to content
XCOMUFO & Xenocide

Building Without Visual Studio


albrot

Recommended Posts

Hello all!

 

I've read the quick start for programmers and had one question. Is there a way to compile Xenocide without having the Visual Studio .NET IDE? I tried a quick search of the forums but wasn't able to find anything. I'm sorry if this has been asked before, but if anybody has a link to a thread or maybe a web page I missed it would be appreciated.

 

Thanks!

Link to comment
Share on other sites

Right now there's no such possibility. We're officialy targeting Windows platform, some time ago one of our developers managed to compile Xenocide for Linux, although due to lack of time we aren't updating that build.

 

Greetings,

Guyver

Link to comment
Share on other sites

Right now there's no such possibility. We're officialy targeting Windows platform, some time ago one of our developers managed to compile Xenocide for Linux, although due to lack of time we aren't updating that build.

 

Greetings,

Guyver

 

Even if you are targeting a Windows only release, there should still be a way to build Xenocide from the command line with the .NET compiler. Is there a list of each libaray's dependencies? I have tried to find one, but haven't had any luck.

Link to comment
Share on other sites

Right now there's no such possibility. We're officialy targeting Windows platform, some time ago one of our developers managed to compile Xenocide for Linux, although due to lack of time we aren't updating that build.

 

Greetings,

Guyver

 

Even if you are targeting a Windows only release, there should still be a way to build Xenocide from the command line with the .NET compiler. Is there a list of each libaray's dependencies? I have tried to find one, but haven't had any luck.

It "should" be compilable with the free Microsoft compiler. If you really want to give it a try, take a look at the Visual Studio project files, they are just plain XML, so you should be able to get the linker settings from there.

For libs, it's mainly boost, log4cpp, luabind, ogre and cegui. Even without the IDE, you can still use the packages from the updater.

 

Rincewind

Link to comment
Share on other sites

What you should also know you have to compile all statically linked libraries yourself with /MT option, since free VC .NET 2003 doesn't have dll runtime libs. So only those packages from Updater will work, which are already compiled as DLLs.

 

You could also try to port project files to Code::Blocks with MinGW. This could make it easier to port xenocide to linux, since there's no platform-specific code in it to date (of what we're very proud :)... well, I'm very proud, don't know about others ;) ).

 

Greetings,

Guyver

Link to comment
Share on other sites

What you should also know you have to compile all statically linked libraries yourself with /MT option, since free VC .NET 2003 doesn't have dll runtime libs. So only those packages from Updater will work, which are already compiled as DLLs.

 

You could also try to port project files to Code::Blocks with MinGW. This could make it easier to port xenocide to linux, since there's no platform-specific code in it to date (of what we're very proud :)... well, I'm very proud, don't know about others ;) ).

 

Greetings,

Guyver

 

 

I've been looking into translating the project files into some type of script that can be run from the command line. Unforutnatly, I've had very limited success, mainly because I can't seem to get the object files to link. I've also found a program that will convert 2003 sln into 6.0 proj files. I've run into some problems with these too though that I've been trying to work through. Mainly, I've had to change the default paths for libraries to be the ones included with the free compiler instead of those that came with 6.0. The going is slow, but I'm getting there!

 

Guyver6, I had a little bit of trouble understanding what you have said. I think you've said that all statically linked libraries need the /MT option or they won't work with the packages from updater. Is that correct?

Link to comment
Share on other sites

I've been looking into translating the project files into some type of script that can be run from the command line.  Unforutnatly, I've had very limited success, mainly because I can't seem to get the object files to link.  I've also found a program that will convert 2003 sln into 6.0 proj files.  I've run into some problems with these too though that I've been trying to work through.  Mainly, I've had to change the default paths for libraries to be the ones included with the free compiler instead of those that came with 6.0.  The going is slow, but I'm getting there!

 

Guyver6, I had a little bit of trouble understanding what you have said.  I think you've said that all statically linked libraries need the /MT option or they won't work with the packages from updater.  Is that correct?

That's what I said. Use /MT for static libs. Oh, and probably you'll have to compile boost yourself.

 

And be aware that VS6 doesn't support lots of neat C++ features that we (and boost) use.

 

Btw, have you tried Code::Blocks?

 

Guyver

Link to comment
Share on other sites

I've been looking into translating the project files into some type of script that can be run from the command line.  Unforutnatly, I've had very limited success, mainly because I can't seem to get the object files to link.  I've also found a program that will convert 2003 sln into 6.0 proj files.  I've run into some problems with these too though that I've been trying to work through.  Mainly, I've had to change the default paths for libraries to be the ones included with the free compiler instead of those that came with 6.0.  The going is slow, but I'm getting there!

 

Guyver6, I had a little bit of trouble understanding what you have said.  I think you've said that all statically linked libraries need the /MT option or they won't work with the packages from updater.  Is that correct?

That's what I said. Use /MT for static libs. Oh, and probably you'll have to compile boost yourself.

 

And be aware that VS6 doesn't support lots of neat C++ features that we (and boost) use.

 

Btw, have you tried Code::Blocks?

 

Guyver

 

 

I haven't had a chance to try Code::Blocks yet. I think I'll have some free time this weekend to look into it. What kind of C++ features were you talking about with VS6? And what exactly is boost? If you've got a link to an explanation of Boost that should be fine. Thanks for your continued interest in my ramblings!

Link to comment
Share on other sites

  • 1 month later...
What you should also know you have to compile all statically linked libraries yourself with /MT option, since free VC .NET 2003 doesn't have dll runtime libs. So only those packages from Updater will work, which are already compiled as DLLs.

 

You could also try to port project files to Code::Blocks with MinGW. This could make it easier to port xenocide to linux, since there's no platform-specific code in it to date (of what we're very proud :)... well, I'm very proud, don't know about others ;) ).

 

Greetings,

Guyver

 

There are problems with getting the code to compile with MinGW or gcc. I tried compiling the source code (not the whole project, just pieces of it) with gcc. As MinGW is a gcc port, the results should be the same.

All packages, like Ogre, DevIL and the rest compile with gcc. It just takes half a day for all of them. Project xenocide's code is a different matter.

 

Most of the problems gcc yells about are pretty small and can be fixed in a couple of hours, I hope (At least the ones I saw took two minutes at most each). The only thing I saw that gcc can't handle at all is a part of the template code. Specifically, specialization of templates inside templates, like in "common/settings/settings.h" is impossible in gcc.

So I downloaded icc with the "non-commercial" license. As someone already wrote a long time ago, this compiler works much better. The problem is, icc doesn't come with any linux distro, the download is 200MB, doesn't seem to install by itself on anything except redhat or suse (I had to extract it and set the paths manually after the install failed), and at least here seems to compile much slower then gcc.

 

I also tried Code::Blocks. It's a pretty nice ide and it imports vcproj files perfectly. The thing is, I have only linux and the importer mixes the slashes and backslashes, so for now the sln file doesn't get imported at all and a path or two in each vcproj has to be fixed. On windows there probably would be only really minor problems, if at all.

There are a couple of other problems coming from the fact that it's linux. The defines needed are a bit different, some library names differ and the install directories of different packages are not that constant going from installed system to another.

 

The last time I was around (more than a year ago) I had only time to contribute with translating...which as I see still hasn't begun? Now I've got more time so I can look at code and I still want to contribute, but it's kind of hard if the code doesn't compile :(

Link to comment
Share on other sites

That is the fact of Linux support, it is way more easier to setup Xenocide to compile correctly and be running in just 15 minutes (proven time). We always encourage linux developers to issue patches that make the source compile in it too; but we do not actively support it (even though we try to write code that is crossplatform, if noone compiles it in linux, we cant know).

 

Greetings

Red Knight

Link to comment
Share on other sites

As for compiling on windows. I have been able to compile using the command line tools with VS .Net 2003 (the IDE). I have not yet tried to do the same from a computer with only the free compiler.

 

Update: I downloaded and installed the free compiler. The toolkit contains the compiler and linker, but lacks a way to read the settings in the .sln file. I also looked at Code::Blocks as an alternative IDE that uses the VC++ Toolkit compiler. Code::Blocks is capable of reading a .sln file, but it complains about certain paths containing too many "..\"s. If we can limit the number of "..\"s we use in the paths, we should be able to compile from Code::Blocks.

 

As for linux, if someone can start a make file (I have no idea where to begin), I can test each revision for linux compatibility. I have both Windows and linux machines available to compile on. (The SVN repository is on one such linux machine.)

Edited by mindstormmaster
Link to comment
Share on other sites

As for compiling on windows.  I have been able to compile using the command line tools with VS .Net 2003 (the IDE).  I have not yet tried to do the same from a computer with only the free compiler.

 

Update:  I downloaded and installed the free compiler.  The toolkit contains the compiler and linker, but lacks a way to read the settings in the .sln file.  I also looked at Code::Blocks as an alternative IDE that uses the VC++ Toolkit compiler.  Code::Blocks is capable of reading a .sln file, but it complains about certain paths containing too many "..\"s.  If we can limit the number of "..\"s we use in the paths, we should be able to compile from Code::Blocks.

So the sln importer has problems on windows too... You could try to open the vcproj files. They seem to work better for now, unless the limit on "..\" is higher on linux.

 

As for linux, if someone can start a make file (I have no idea where to begin), I can test each revision for linux compatibility.  I have both Windows and linux machines available to compile on.  (The SVN repository is on one such linux machine.)

Great ^_^

I'm reading some tutorials and a book about making autoconf scripts for building libraries and programs. I started reading it with no connection to xenocide, but this will be more fun and give me some very live code to deal with :D

autoconf scripts will be more appropriate and easier to modify as the code evolves. Will take a while but I'll write them.

 

I should post in the reqruitment center when I have a patch ready, no? But on what profile? And the first patch will probably be something like "stick space in '<:: to fix some gcc and icc errors>

Edited by reist
Link to comment
Share on other sites

Yes, but I hardly know how to write autoconf scripts at all.

On the other hand, I have a lot of time currently, so I should be done in a couple of days at most :)

And anyway, I want to do more than make it compilable on linux.

Edited by reist
Link to comment
Share on other sites

I should post in the reqruitment center when I have a patch ready, no? But on what profile? And the first patch will probably be something like "stick space in '<:: to fix some gcc and icc errors>

When you have the patch ready, post it in the recruitment center and will be moved to the programming forum by an admin. About the profile, dont worry as there will be some opening in the near future for different profiles.

 

Greetings

Red Knight

Edited by red knight
Link to comment
Share on other sites

Right, I almost have a full patch. xenocore, xenocommon and xenolauncher compile (with a lot of warnings on some files). The only problem is xenoui.

Two geoscape files - baseviewrenderer.cpp and earthpane.cpp use two OGRE functions that don't exist even in cvs - Ogre::Camera::setFrustumOffset and setFocalLenght.

Except for these two, all files that are inside the four vc projects compile (with ICC). The xenotest project failed, though. Is it old code?

 

Also, I now have a Code::Blocks workspace with all the projects in it. The ability of Code::Blocks to import vcproj files really helped here. There were some bugs with the import, but they were easily fixed. The problem is all the compiler and linker options. I only changed the copied setting enough for everything to compile. I'm still planning on doing a configure script.

Link to comment
Share on other sites

Did you consider using something like premake?

 

On the other hand ufo2000 is currently in the process of switch from plain makefiles to scons as we need to figure library dependencies automatically, have some complicated things done in the build process and need more flexibility :)

Link to comment
Share on other sites

Those setFrustumOffset and setFocalLenght functions are part of guyver6's patch to Ogre...and yes that's the way he chose to spell that.

 

I suspect you'll have to talk to him about the changes between the version of Ogre we use (I think it's only different in one or two files) and the cvs.

Edited by Kikanaide
Link to comment
Share on other sites

Did you consider using something like premake?

 

On the other hand ufo2000 is currently in the process of switch from plain makefiles to scons as we need to figure library dependencies automatically, have some complicated things done in the build process and need more flexibility :)

Well, no. I don't really know any of the build systems. Until now I just used them. I am familiar with makefiles, so I'm going with autoconf.

Anyway, thanks for the suggestions. I really should see what they can do.

 

We are using the latest stable release from Ogre, are you sure that you have the lastest Ogre version?

 

If you have an automatic building process for linux, we are glad to host it.

 

Greetings

Red Knight

 

I'm pretty sure I have the last version. I build all the packages in the last three days. Then I had to get ogre from cvs to fixed another file from geoscape. So these two files are all that's stopping me from seeing if everything works or just compiles.

 

Nothing automatic yet, but if anyone wants it there's the Code::Blocks workspace. I think it's usable (at least for building) :fingerscrossed:

The problem is that the paths are static, so if anyone wants to use it, they'd have to modify the paths per project or have boost, ogre, cegui and lua installed in the same places (with prefix=/usr).

Link to comment
Share on other sites

Yes, of course. There's just the problem that I can't add attechments (ie only?).

I've open a small http server on my computer for now. There're just the patches I made and the codeblocks workspace. I made the directory structure to be a copy of the devpack.net2003 one.

84.228.89.129:8000/

Link to comment
Share on other sites

reist, I have tried to integrate your patch but even if it compiles it breaks the buttons (they stop functioning - for example the Start New Game one). Until it works the patch is rejected.

 

Greetings

Red Knight

Edited by red knight
Link to comment
Share on other sites

  • 2 weeks later...
reist, I have tried to integrate your patch but even if it compiles it breaks the buttons (they stop functioning - for example the Start New Game one). Until it works the patch is rejected.

 

Greetings

Red Knight

All fixed.

What I'd like to know is who was the genius who put "typename" in front of a function call.

When I just tried compiling everything, before reading the code, I saw an error about something not being a typename and commented it out.

 

I'd like to thank whoever put the "typename" there. Even buy him a beer :beer:

Thanks to the holdup (and some talks with guyver) the patch now makes xenocide GCC compatible. No need to install intel's compiler on linux.

As I can now run xenocide, I can say that everything works (at least on linux), except for some weirdness in xnet - it stalls and if I send a kill signal, it resumes, just with no text on it's buttons and no entry graphics. The entry text still appears. Everything else works well, before and after entering xnet.

 

I also wrote a scons script that should work with GCC or ICC. I put it on my ftp with the patch. It may have some things that are specific to my linux distribution, so anyone trying it can tell me about any problems or send me a fix for them.

 

ftp with patches

 

edit: Oh, if anyone could try to build xenocide+patch with mingw, it would be really cool. =b

and another thing: the file patch-summary inside the archive has a note about some needed file renames (case sensitivity and all)

Edited by reist
Link to comment
Share on other sites

OK, done.

Just an update on the XNet problem: it's linux-specific only, maybe even my computer-specific.

The stalling is caused by some problem in changing sound - sdl, driver, I don't know yet.

The graphics could be caused by the driver(ati had bad driver reputation even on windows) or by ogre cvs.

Link to comment
Share on other sites

  • 2 weeks later...

Is there a possibility that someone else will check the patch? Mindstormmaster was (and still is) pretty busy with other stuff and I can't fix possible windows problems with it with no feedback.

This patch is against current svn head.

 

I put the patch somewhere more stable - my university user account site. Really don't know why I didn't think of this earlier :doh:

www.cs.biu.ac.il/~peterbb

Link to comment
Share on other sites

Ok, should be downloadable now.

...This is weird. Last time I tried, I couldn't upload anything to the forum.

Edit: You should also look at the end of the patch-summary files. There are some file with the wrong case. I can't patch that.

patches.zip

scons.zip

Edited by reist
Link to comment
Share on other sites

> - ActionMapDialog* should be actionmapdialog*

 

Oops... That one's mine. Fixed.

Thanks :)

One rename down, one to go.

I don't know if whatever is used to patch on windows is case sensitive or not, but here's the patch, updated.

patches.zip

Link to comment
Share on other sites

It compiles and runs (release, debug still builds...). I found no introduced bugs (although I didn't really searched :)).

 

Edit: Debug works also. RK, should I commit it?

 

PS (not about the patch):

Why xenocommon was set to build without RTTI in release? Or was it only me?

 

PS2: I, of course, have no idea if this works anywhere besides VS2003 :).

 

PS3: Those builds take forever. Does somebody want to donate a shiny new PIV to me? :)

Edited by UnFleshed One
Link to comment
Share on other sites

Well, I didn't exactly add anything. I just fixed all the errors ICC and GCC screamed about, fixed about 90% of the warnings GCC gives with -Wall and a couple of other flags active and fixed a really annoying segmentation fault happening just before the program fully exits. So if VC had complained, it woul've been really weird and would mean more #ifdefs to fix.

 

The warnings I left were conversions from float/double to int, initialization order in the constructor and two ICC warnings about doing if(true) with a float (the "it can be reaaaal close to zero, but not zero" problem). I have all float warnings in a list, though.

 

There is still one thing that the patch can't do - a texture's name differing from it's reference in the xml files: BVT_door.png. It's not fun when you get kicked out of baseview because a texture that exists can't be found. =p

 

Seeing the patch works, should I make a list of "good practices to follow for multiplatform compatibility" or something of the sort? Looking at the patch-summary I wrote, there'd be about six items in such a list. Any other problem can only be found by compiling on GCC and other compilers.

Link to comment
Share on other sites

Heh, yeah that's what I thought.

Well, I don't have anywhere else to post it, so here goes: :P

 

Case sensitivity in file names - includes, xml/xsl files, anything.

For example: "CEGUIEvent.h" and not "ceguievent.h"

Or from an xml file:

xsi:schemaLocation="GlobeIcons globeicons.xsd"

and not:

xsi:schemaLocation="GlobeIcons globeIcons.xsd"

 

Use "

Cause: Seems there were sometime keyboards that didn't have square brackets. "<: and>" as a replacement still exist.

For example: "getType" instead of "getType<::string>"

 

In standard C++ enums are referred to without the enum type. That's a microsoft import from java/c#.

For example: "Key::Return" and not "Key::Scan::Return"

 

Static variables inside a class (or template) should be redeclared with initialization immediately after the class in the header file if they are meant to be used in more than one cpp file. Otherwise some compilers complain about undefined symbols.

If the static is meant to be used in one cpp file only, it can be redeclared in the file. For example, any of the class loggers.

If there was no initialization, just redeclaration, initialization will have to happen somewhere else. For example, the new connectStubs function in uimanager.cpp for all events that don't do anything yet.

 

Function pointer should have "&" prepended, especially member function pointers. Some compilers get confused otherwise.

 

Don't forget to put "include namespace Namespace" or "Namespace::".

VC seems to guess where classes, functions and variables come from. Some compilers don't.

 

Const casts. These only cause warnings, but forgetting that it's a const may cost you.

For example:

void DoSomething(const someClass X) {

const otherClass Y = (const otherClass) X;

...

}

Or even better, use static_cast. For example: static_cast(X)

Edited by reist
Link to comment
Share on other sites

SCons is a python based replacement for makefiles. The files go into the xenocide directory and right it's subdirectories, in the same structure as the zip file.

This script should build the game in debug and release mode on linux with GCC or ICC. The intel-win32 file is a leftover from where I found an example on how to set compilers in scons. I hope someone uses it and reports/fixes things that may be specific to my linux distribution that I missed.

It could be modified to support any other compiler on any platform.

Just copy one of the .scons files, modify the new file, modify the couple of lines necessary in the main SConstruct file, and that's it.

 

I wrote the scripts based on files and not wildcards, because some files/directories are not used. That means the corresponding SConscript file needs updating everytime someone adds/removes/renames files in it's directory or subdirectories. It's really easy, just editing the file name. All the other parts of a build configuration are out of the way.

Link to comment
Share on other sites

UnFleshed One, couldn't agree more. The problem is xerces, ogre and cegui are already there and are not lowercase.

Edit: Everything in xenocide can be lowercase, but any includes to those three will have to use their names and case.

Edited by reist
Link to comment
Share on other sites

The files go into the xenocide directory and right it's subdirectories, in the same structure as the zip file.

 

Can you make it go into /devpack.icc/compiler or something? Like /devpack.net2003/compiler. So we have one way of doing this.

 

Edit: Azrael, it is only part :). Full one is here: http://www.xcomufo.com/forums/index.php?sh...=136329�

 

Edit2: Er... I mean post 37.

Edited by UnFleshed One
Link to comment
Share on other sites

The only difference between them is using intel-linux.scons file or gcc-linux.scons file which set the compilers' program name, basic flags and includes. There also something like a switch happening in SConstruct to add a couple more flags based on what options you gave to SCons. All the other files stay the same.

 

There's a check in one file to see if boost is compiled with icc or gcc because this changes the name of boost's libraries, but I'm pretty sure this can be removed - people who really use icc will use it for everything.

Anyone who has gcc 3.4 and up (can't compile luabind) will probably prefer to install gcc 3.3.6 in parallel and not deal with icc at all.

 

Of course, I could be wrong about this, but I can just save the check somewhere else.

Edited by reist
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...