COMPILE: Linux Port

[dmg]

What's the status of the Linux port? The Linux subversion branch was last touched back in February. I have a small patch that fixes all the extra qualifications, so I could at least get it to build with gcc-4.1 and ubuntu edgy.

I've started a merge from trunk revisions 444-656 into the Linux branch. There are about 1300 conflicts in 400 files. I wrote a small perl script to automatically fix about 100 which are exact-or-whitespace-only duplicates, but that still leaves a lot of work for the others. They mostly look like simple fixes, but it's still going to be a lot of work. Is this something I should spend my time doing?

[Ekmek]

dmg,
I'd say keep it up. J Bytheway will probably get to this post soon. He's the main one i've seen still active on linux though there are a few others.

[J Bytheway]

I was the last person working on it, but I've stopped now for complicated reasons. The main issues, as I see them, are the merging issue, that you seem to alredy be aware of, and problems with the graphics. The latter may be repaired by the former.

I think ctplinuxfan was working on merging, and he had decided it would be best to do it a revision at a time rather than do the whole lot at once (see this post, and the following few). There's an alternate branch (branches/linux-merge/) where he was working. That's all I know about the merging progress.

[dmg]

Yeah. Now that I've actually started looking at the merge, I decided it might almost be easier to try to re-port trunk to Linux using the linux branch as a basis for the work. There were only 127 files that matched
a grep for #ifdef LINUX / #ifdef WIN.* , so all in all the code is at least _somewhat_ isolated. I must at admit, some of the conflicts are much more annoying to fix, and would be better off to simply replace the entire file with the version in trunk and then add the Linux-specific code back in.

I'd consider starting to do this, but since I'm unfamiliar with the codebase (I can do the grunt work of porting the #ifdef LINUX code from the linux branch), so all the other (hopefully minimal..) changes that were done in the linux branch that _weren't_ protected would get lost.

It's a shame the branch got so out of sync.

[J Bytheway]

Originally posted by dmg
I'd consider starting to do this, but since I'm unfamiliar with the codebase (I can do the grunt work of porting the #ifdef LINUX code from the linux branch), so all the other (hopefully minimal..)

They are, unfortunately, far from minimal (try running some appropriate diffs). Quite a lot of them were made my me before I really understood how to write C++, so it might be good to lose them, but there are also a fair few things that you probably wouldn't want to redo (like the porting of the interface to SDL)

changes that were done in the linux branch that _weren't_ protected would get lost.

It's a shame the branch got so out of sync.

Indeed.

[ctplinuxfan]

Like Bytheway i stopped some time ago working on the port. The main reason was i have no internet access at home. The one i can use does not allow usb devices to be connected anymore. Before that, i used svk with kdiff3 for merging and ~/.svk on an usb stick.

Originally posted by dmg
Yeah. Now that I've actually started looking at the merge, I decided it might almost be easier to try to re-port trunk to Linux using the linux branch as a basis for the work. There were only 127 files that matched
a grep for #ifdef LINUX / #ifdef WIN.* , so all in all the code is at least _somewhat_ isolated. I must at admit, some of the conflicts are much more annoying to fix, and would be better off to simply replace the entire file with the version in trunk and then add the Linux-specific code back in.

I think i'd do the same after that many changes. My last plans were to merge /trunk as soon as possible to /branches/linux and keep them at sync. When /branches/linux was stable on both win and linux, update /trunk to /branches/linux.

I agree it's a shame /branches/linux went out of sync; i was the only one merging...
However, you will save alot of work, if you directly commit on /trunk when you start from scratch. Even, if you have no windows (and cannot test using visual studio express), breaking changes on either side can be fixed easier when occuring, i.e. when code is in sync.

I'd consider starting to do this, but since I'm unfamiliar with the codebase (I can do the grunt work of porting the #ifdef LINUX code from the linux branch), so all the other (hopefully minimal..) changes that were done in the linux branch that _weren't_ protected would get lost.

You will also have to look at ctp2_code/os/* files, and other macros like e.g. USE_SDL and AUI_USE_SDL. Also, the aui_* code was designed for multiple platforms by activision, but perhaps under time pressure code for directx was hooked in here and there.

One conflict i remember is in the cd subsystem, because c3files has been redesigned when i implemented the sdl cd-check code.

[RichardH]

Hi there, I've just stumbled across the ctpII source code project and I'm interested in contributing to the linux porting effort. I've been programming in C for 20 years, but my exposure to C++ is somewhat limited. I am, however, a ctpI addict, and this seems to be a nice, simple project to get involved in.

I've read the EULA and performed an anonymous checkout of /branches/linux and /trunk.

So... anyone have any suggestions about where to start?

[Martin Gühmann]

Originally posted by RichardH
So... anyone have any suggestions about where to start?

Well if you are interesting in porting CTP2 to linux, you may merge in the windows revisions step by step so that the two branches get back in sync. But if you think this is bring you maybe play the game and look where you can fix or add something.

-Martin

[RichardH]

I think that bringing the branches back into sync is an important step, and probably necessary before doing anything else, however boring.

Except that I'm having difficulty compiling the Linux port because of the New Reality (tm) enforced by the gcc 4.1 compiler. I'm currently working through the errors, and I should probably have them finished by the end of the weekend. Once I've finished, how can I get the chances committed to the linux branch?

[Martin Gühmann]

Originally posted by RichardH
Once I've finished, how can I get the chances committed to the linux branch?

Ask DarkDust to get an account. For more information about the server read this thread. Well at least the important parts.

-Martin

[RichardH]

I've committed revision 670 to the linux branch. This fixes compilation for gcc-4.1 by removing extra qualifiers:: and moving the PACK attribute to the end of structs instead of packing each element individually.

[Ekmek]

is there a way we can keep them in sync? i guess besides the obvious of having a linux guy keeping pace with the changes on the other side.

[RichardH]

Aye, that's the next phase of my cunning plan.

I'm currently considering the best way to achieve it; as discussed above, the branches are now so far apart they can't even contact one another by shouting.

I'm a subversion newbie. Is there a way to identify which changesets have been applied to which branch? If not, it might be easier (again, as discussed above) to start again with the trunk and re-apply all the linux specific changes to it to recreate the linux branch...

[Ekmek]

http://ctp2.darkdust.net/archives/ctp2-commit/

this site gives all of our commit records much like our thread but it will tell which branch i believe.

[RichardH]

Hmm. That's useful, but the problem as I currently see it is that there have been some merges from trunk, but not necessarily in sequence. There are also things that have been added to trunk, played arond with and then removed months ago, all of which the linux branch knows nothing of. Merging is going to be painful.

I'm going to think about it for a couple of days