Reorganization

skyjake

<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Engine, Games, Mac OS X, SourceForge, Unix/Linux, Windows.</i>

The restructuring of the sources will commence very soon. I will commit the new directory structure and relocated files tonight (apart from Defs, Src, and Include, which will have to wait for tomorrow). All of this is happening in the trunk, so branch-1-9-0 remains usable. It should be possible to do bug fixing on branch-1-9-0, although I don't recommend committing much because merging them back into the reorganized trunk may prove tricky (although Subversion should be able to handle it).

Please note that once the files have been relocated, all build scripts and project files become obsolete. makedmt.py and other scripts need to be checked for path references. On Windows (<tt>/build/win32/</tt>), the old dsp, dsw, and vcproj files should simply be deleted until replaced with updated versions (if that is ever done...).

EDIT: The SF.net SVN server is giving me a "403 Forbidden" error message. OK, I'll try again in the morning...

EDIT#2: Still getting the same error message on commit, even though I activated the new SVN write access access flag. Hmm...

DaniJ

Just thought I'd wish you luck with this for this weekend

I commited to SVN (trunk) myself early this morning and everything seemed OK.

skyjake

It seems to be working now. The first set of moves is going into the repository. I'll start working on the Defs, Src, and Include directories now.

Revision 3275 has relocated files for everything except Defs, Src, and Include.

DaniJ

It's looking a lot more organised already.

As to the VC++ project files I'll set myself up with the new 2005 free edition once the source tree is finalized and generate them again.

While I think of it doomsday_res.obj is always missing from the win32 source packages and has to be gotten from the old dev package seperately.

skyjake

I think all the files have now been relocated. A couple may have ended up in the wrong directory, and should be moved as appropriate.

The deal with the <tt>portable/win32/unix/mac</tt> subdirectories: if the module has platform variants of certain files, these subdirectories are used for separating them. There are <tt>src</tt> and <tt>include</tt> directories inside each platform-specific directory (also <tt>res</tt> in some cases). If the module is completely platform-independent (like all games should be), then the platform variant subdirectories are omitted entirely (although having just the "portable" directory is OK, but a bit pointless).

The compiled win32 resource files (doomsday_res.obj) should be committed into the "engine/win32/res" directory.

skyjake

When it comes to the runtime data, we should make a portable (Python) script that creates a PK3 with the correct files in the correct places. In fact, Doomsday.pk3 already contains most the files. I'm thinking the games' startup.cfg's should be included somewhere. Perhaps a game-specific .pk3 file? So that we get the nice game-theme UI colors for the Doomsday UI. And of course, the game .ded files needs to be packaged appropriately into a virtual <tt>Defs/(game)/</tt>.

DaniJ

<blockquote>I'm thinking the games' startup.cfg's should be included somewhere. Perhaps a game-specific .pk3 file? So that we get the nice game-theme UI colors for the Doomsday UI. And of course, the game .ded files needs to be packaged appropriately into a virtual Defs/(game)/.</blockquote>
Yes I think a jDoom.PK3 for example would be a good idea.

I'll start updating the vcbuild bat files for this new layout.

EDIT:

Oh dear. The input line in the call to cl in vcbuild.bat for Doomsday.exe is now longer than that allowed by the shell. We'll have to look at either:
<ul>
<li>Use a linker response file
In which case build will have to take place in \doomsday as opposed to \doomsday\build\win32 - due to not being able to pass parameters from the BAT file to the response file (otherwise full paths would need to be specified) OR generate the response file dynamically (perhaps from a py script).</li>
<li>Use an incremental build</li>
</ul>

skyjake

<blockquote>Use a linker response file
In which case build will have to take place in \doomsday as opposed to \doomsday\build\win32 - due to not being able to pass parameters from the BAT file to the response file (otherwise full paths would need to be specified)</blockquote>Using a response file is recommended. Wouldn't it be possible to just use relative paths like ../../engine/src/something.c?

Yagisan

I'm currently swamped for time, so it may be a few days before I can begin commiting updates for the *NIX build system. I believe I can take care of auto-generating any .pk3 files in shell script on *NIX, Win32, and MacOS.

DaniJ

<blockquote>Using a response file is recommended. Wouldn't it be possible to just use relative paths like ../../engine/src/something.c?</blockquote>
Yeah thats possible but only if the build takes place in /trunk/Doomsday instead of /trunk/Doomsday/build/win32/ as I thought thats where you wanted it to happen?

EDIT:
Doh! Nevermind I see what you mean now.

DaniJ

I've updated the win32 build script, added response files for the included file lists, updated all src files with the new lowercase file naming standard and removed the old vcproj files.

skyjake

Dani, note that some of the files have been moved (e.g., lzss.c).

I have now updated the Xcode project so that I can build and run the game. The next thing to take care of is the generation of the PK3s that are organized using the old Defs/game & Data/game system, so that at runtime the engine can access files from there. Yagisan, any progress on the .pk3 script?

Yagisan

No progess on the pk3's at this stage (lack of time). I've started work on the *NIX build system (need to commit that soon). It won't be too hard to whip the script up, but I'd really like to be able to build deng again first. (You have autotools on OSX ? A few users on IRC have tried to build beta4 on OSX using the *NIX build scripts, and it seems OSX puts things in different places)

dengDevs Import

<i>This comment was posted by dengDevs user <b>byteframe</b>.</i>

Hey hey hey.

I was wondering, that instead of having the doomsday install all the files into $prefix/lib,include,share,bin I was wondering if it was possible to have tell configure to put all the files in something like

"/usr/local/games/doomsday"

I tried the --prefix=/home/byteframe/doomsday (testing all this out) and it worked. I moved bin out from doomsday/bin to doomsday and it still knew where to find the libraries files.

I would like to do a loki installer for doomsday, and for those of you who don't know, it allows you to change the installation direcotry, however, since the instlaler will be installing precompiled binaries, how would I make it so that the location selected in the installer, works for the binarys, which are precoded to have a specific place, work?

this is hrad to replain, but I would think maybe it can work. Also, would there be a way to just have the doomsday binary look for the librarys and other files relative to ITs location?

Get back to me, thanks.

skyjake

Let's make a new post for the Unix installation discussion.