COMPILE: Linux Port

[ctplinuxfan]

Originally posted by Joss
Hi,
Im wonder if anyone is still working on a linux port, and where to get the few pathes for it. I would be happy to contribute to a linux port.
Cya

Hi,

due to the count of answers i'm afraid nobody is continuing on it atm. Though, it would be great to have somebody who aids on this!
I've a lot of work to do and am moving, which prohibits me from continuing on it for some time. The main things i suppose have to be done are (perhaps in that order):

• create branch with apolyton sources on subversion repository for linux port
• merge sources from closms cvs into that branch
• use autoconf/automake mechanism
• make the code compiles with vc6 and work under windows
• bug fixes
• milestone 1: merge back to apolyton main codeline and sync branches
• merge patch by johannes sixt into linux branch, without removing the original cd check (i.e. reimplement sdl version for linux)
• when merging this patch, also provide native DirectX code by implementing aui_sdl abstraction layer
• check that code also compiles with vc6 and works under linux and windows
• bug fixes
• milestone 2: merge back to apolyton main codeline and sync branches
• result: first working linux version with mouse support only
• implement abstraction for user input by both DirectX and SDL
• verify it works under windows and linux
• bug fixes
• milestone 3: merge that back to apolyton main codeline
• result: linux version with keyboard input
• implement cdrom volume settings for linux and windows with sdl providing native directx code
• bug fixes
• merge back and sync with apolyton main codeline
• implement installer (perhaps a script first that unpacks the archives
• bug fixes
• milestone 4: merge with apolyton code line, sync branches
• result: releasable source package (if agreed to eula) or binary builds
• fix network game play
• bug fixes
• milestone 5: merge and sync..., native ctp2 for linux, network games with windows clients possible
• bug fixes
• milestone 6: sync codebase suitable for other ports efforts, if any

So to get started, you'd need to mail closms to get access to the cvs server and ask kaan to get access to the subversion server once it is up.
When i can spend some time again, i will add windows related project files for building an SDL version of civctp2 under windows as well (i have started on them, but maybe need to resolve some conflicts).

[Capehill]

Your plan sounds good, are there any news?

I got just an access to the SVN server and I'm interested to try AmigaOS port using SDL, but as far as I know, the sources on that SVN server use DirectX.

I'd like to help but my time is also very limited...

[J Bytheway]

I finally got around to checking out the sources on my linux box and got as far as running make, and quite a few things appear to actually compile - congratulations on your work so far . I'd be interested in helping with a linux port, but I'm afraid I'm somewhat ignorant as to what is necessary (e.g. the first compile error I hit was an undefined function, and brief investigation gave no clues as to where it should be or even really what it was - what does one do in such situations?). Is there anywhere that documents this sort of thing, or can you only learn it as you go along?

[ctplinuxfan]

You can learn as you go along, but if you find a tutorial, please let me know.

For undeclared errors, there may be these cases[list=1][*]missing include in .c/.cpp file with the error
Find out, where the prototype/the function is defined (e.g. using ctags) and add that header file to the #include list in the .c/.cpp file[*]function/type used available on windows only, see points below[*]the function uses windows related datatypes (e.g. MBCHAR, LPVOID) as parameters or return values and reading it's documentation at msdn.microsoft.com, you found a replacement function which does the same, e.g. WIN32 CreateDirectoryand Unix/POSIX mkdir
Replace the code like this

#ifdef WIN32
        return CreateDirectory(path, NULL);
#else
   mode_t mask = 0777;
   return mkdir(path, mask);
#endif // WIN32

[*]The function does not use windows related datatypes or you don't know a replacement
Add its prototype definition to os/nowin32/windows.h
Also add type definitions for the parameters, if not in windows.h already[/list=1]

enum forward declaration errors:
Locate the header with the definition of the enum and add move it's definition to ctp/ctp2_enums.h. In the header file, add the line #include "ctp2_enums.h"
Remove the enum ITS_NAME; line and replace it with #include "ctp2_enums.h"

I cannot test the last changes on windows ATM, so i'll create a linux-branch now with more up-to date changes. We can merge the changes to trunk frequently, when they have been tested on windows, too.

So checkout the linux stuff at svn://stp2.kaan.dk/ctp2/branches/linux

HTH,
Holger

PS: There is a book titled Programming Linux Games, but it does not cover porting afaik (read about it on freshmeat.net). Perhaps you can get this book at a library, it'll give you an overview over linux and game programming. At least that might ease the task finding an equivalent implementation of a windows function.

[ctplinuxfan]

The linux branch is created now...

[J Bytheway]

Well, one thing I noticed is that if you don't have byacc it doesn't complain sufficiently loudly (the error message defined in configure.in doesn't appear).

[J Bytheway]

Originally posted by J Bytheway
Well, one thing I noticed is that if you don't have byacc it doesn't complain sufficiently loudly (the error message defined in configure.in doesn't appear).

...which I've now fixed . I'm surprised I was able to comprehend configure.in sufficiently.

[J Bytheway]

Well, I've had some fun this evening trying to make civ3_main.cpp compile. I've fixed things as best I can, but since I'm new at this I would appreciate it if you glance over what I've done and tell me if I did anything stupid.

I encountered the enums DEFAULT_PLACE_POP and MSG_CLS which appear not to be defined anywhere - I wonder if they were removed at some point and there are still references to them lying around, but I would have thought that would have caused compilation errors under Windows...

The next batch of errors are of the form:

ctp2_code/ui/aui_common/aui_listbox.h:291: error: friend declaration
   requires class-key, i.e. `friend struct aui_DropDown'

Is it safe to simply follow the advice of the error messages in this case (which is what Googling suggests)?

[ctplinuxfan]

J, your changes are pretty good

DEFAULT_PLACE_POP and MSG_CLS aren't used, obviously MSVC does allow a forward declaration of anything, as long as its not used, it does not complain.

For friend, you can simply follow what the messages suggest. According to Std-C++, friend needs a type specifier, i.e. something of

friend class fooclass;
friend struct foostruct;
friend void foovoid();
friend footype operator();

Make sure you use the same type, i.e.
friend class aui_DropDown;

if aui_DropDown is declared to be a class.

[J Bytheway]

OK, thanks. Now I think I've got all the headers of civ3_main.cpp being handled without errors.

Some more things that have been worrying me:

When checking for compilation under win32, why do some places use "#ifdef WIN32" and others use "#ifdef _WIN32"?

I'm not sure about the wisdom of putting all (or most) enumerations in one file - I don't like the fact that this one file has such disparate conntents, which seems like bad programming style. Why did you choose to do this rather than simply including the header files which already contained them? Personally, I think I would be more inclined to create a seperate header file for each enumeration, but I always have a tendency to proliferate files when programming.

[ctplinuxfan]

_WIN32 is used by original code, WIN32 has been introduced by me or others. Actually some compilers define _WIN32, some WIN32 on Windows, and some neither. For newer Microsoft compilers, _WIN32 doesn't mean sizeof(void *) == sizeof(int) == sizeof(long) == 4, because it's also defined on x86_64, for which _WIN64 was introduced.

I simply took WIN32 to indicate it's Windows code and it needs to be reviewed for possible compiler/architecture issues later.

Some headers are cyclical included, because the types they define are used in any of them and are forward defined. So i chose moving the enums into a seperate file to unroll dependencies. E.g. i remember enums needed from keymap.h and aui_tabgroup.h could be fixed by additional inclusion. Sorry if i thought of something simple to start with.

However, this file is still thought to be a container for enums to be refactored into other files when refactoring makes sense. We will have to get along some issues of which i think we need to refactor some parts of the code (e.g. type punned pointers in event system and non-static class methods used in arrays of callback functions, the later is in newdb if you turn -fms-exceptions off).

[J Bytheway]

Originally posted by ctplinuxfan
_WIN32 is used by original code, WIN32 has been introduced by me or others. Actually some compilers define _WIN32, some WIN32 on Windows, and some neither. For newer Microsoft compilers, _WIN32 doesn't mean sizeof(void *) == sizeof(int) == sizeof(long) == 4, because it's also defined on x86_64, for which _WIN64 was introduced.

OK. Thanks for the explanation.

Some headers are cyclical included, because the types they define are used in any of them and are forward defined. So i chose moving the enums into a seperate file to unroll dependencies. E.g. i remember enums needed from keymap.h and aui_tabgroup.h could be fixed by additional inclusion.

Right, that makes sense .

Sorry if i thought of something simple to start with.

Simplicity has its merits .

However, this file is still thought to be a container for enums to be refactored into other files when refactoring makes sense.

OK. I feel we might want to start making a list of these issues that need to be looked at later.

We will have to get along some issues of which i think we need to refactor some parts of the code (e.g. type punned pointers in event system and non-static class methods used in arrays of callback functions, the later is in newdb if you turn -fms-exceptions off).

Well, I have almost no idea what that means .

[J Bytheway]

I see that you did mostly the same things as me to those headers, but you did some of them better . Following your lead, I've now managed to get civapp.cpp compiling, but I'm not sure about some of the things I've done - notably the USE_COM_REPLACEMENT guards and the slightly silly way I'm calling nanosleep.

Next on the makefile's list is display.cpp, which I presume is probably going to have to be almost completely replaced by SDL-related stuff, so I've no idea what to do there.

[ctplinuxfan]

Yes, you've done your changes very well

I hopefully added all other sources to the ctp/Makefile.am.

What i'd like to see changed is the top Makefile to be removed and GNUmakefile.am added as Makefile.am instead.
It allows other make programs to also perform a build. The other gain would be, that IDEs like e.g. kdevelop display the targets of the project and display the classes in the classview. We could move the original makefile into an admin dir, like e.g. some kde projects do it, to make its targets available without automake.

Anyways, i tried but reverted this, since i don't know who else uses the Makefile atm.

Well, more and more stuff compiles. I'd like to seperate some compilation tasks into the associated subdirs to generate conveniance libraries, as we proceed. This should reduce compilation and linking time theoretically, because only the executable and the conveniance library with the sources you changed will be relinked if you just change .cpp files later on (i.e. no header file included by anything like c3.h)...

[Edit]Text cut with the mouse added again.

[J Bytheway]

Originally posted by ctplinuxfan
What i'd like to see changed is the top Makefile to be removed and GNUmakefile.am added as Makefile.am instead.
It allows other make programs to also perform a build. The other gain would be, that IDEs like e.g. kdevelop display the targets of the project and display the classes in the classview. We could move the original makefile into an admin dir, like e.g. some kde projects do it, to make its targets available without automake.

Anyways, i tried but reverted this, since i don't know who else uses the Makefile atm.

Well, I suspect I'm the only one who uses it, and I certainly don't mind it being moved into some other appropriate place. I think anyone else who uses it will be able to cope as well, provided the change is mentioned sufficiently obviously in the revision report.

Well, more and more stuff compiles. I'd like to seperate some compilation tasks into the associated subdirs to generate conveniance libraries, as we proceed. This should reduce compilation and linking time theoretically, because only the executable and the conveniance library with the sources you changed will be relinked if you just change .cpp files later on (i.e. no header file included by anything like c3.h)...

Sounds good .

Besides errors in improveevent.cpp, There seem to be a lot of warnings which concern me. They are mostly in the events-related files so I guess they are results of the "type punned pointers" you were mentioning...