Yagisan's todo list

Yagisan

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

While Skyjake and Dani J are busy working on new features, and making deng the best looking engine around, I thought I'd post my TODO list, so people could see what it is that I've been working towards. It's no surprise that a 64bit deng is a goal of mine, but before that can happen, there are quite a few other things that need to be done first. Indeed looking at my list, it becomes obvious that some things may not be complete until 1.9.1 or so. So without further ado, and in no particular order, my TODO list for deng.
<ul>
<li>Document licenses on all source files. Run list by Skyjake & Dani J first.</li>
<li>Retool the autotools based build system to use external libaries where possible, falling back on the local copy if external is not found.
Need to run these by Skyjake & Dani J first.
Libs affected are:
glbsp
sdl
zlib
libtool
any others I missed.</li>
<li>Discuss, and investigate the feasablity of migrating to a single autotools based build system that can build on:
Linux/*BSD
Windows NT/2k/XP (MinGW)
MacOSX powerpc (Fink)
if possible Windows NT/2k/XP (Visual C++ Express Edition)</li>
<li>Examine code, and begin migration from native C types to types to aid in porting to new systems and architectures.</li>
<li>Examine code, and highlight portablity issues (eg int into pointer, etc), and discuss alternate solutions with Skyjake and Dani J</li>
</ul>

skyjake

These sound good to me. Are you working on any of these at the moment? Anything you would like to discuss at this stage?

The current *nix build system probably stays in place for Beta 4, or what do you think?

Yagisan

The current *NIX build sytem will go in beta4.

I've begun installing some Operating Systems into VMWare to aid in porting work. I've set up Windows 2000, Nexenta Elatte (Solaris based), and Ubuntu Dapper (Linux based). I've just installed Darwin 8.01 (OSX 10.4 is based on this), but that needs a bit of work to setup, and I'll need to learn how to use it. Getting the build system to work on Darwin, means it should then work on OSX, and you'll be the guinea pig to actually test it on OSX.

I'd like to move to the new source layout ( http://www.dengine.net/blog/?p=37 ) after the beta4 release, as that will aid in making a robust portable build system.

DaniJ

<blockquote>I'd like to move to the new source layout</blockquote>Yes, I suggest that should be perhaps the first job after the Beta4 release.

skyjake

<blockquote>I'd like to move to the new source layout</blockquote> Me too. After Beta 4 has been released, let's organize the source files and directories into the modular system described in the earlier post. However, I suggest we leave the runtime directory structures untouched during Beta 5. Let's not try to do everything at once. It's also good to make a clear separation between the source directory structure and the runtime structure.

Yagisan

OK. The removal of Doomsday.wad broke the linux (autotools) build scripts. I don't see the Doomsday.pk3 file that is meant to replace it, is that not implemeneted yet ?

I'm about 50% through making the new autotools build scripts, depending on how soon until release I can either patch the scripts if release is imminent, or drop the new system in and continue work on it until release. The new system is based on Automake 1.9, Autoconf 2.59 and Libtool 1.5.22.

Skyjake, I see notes in the source that libtool is broken on OSX. the version of libtool we bundle is rather old (and has security issues). We should remove it from the source tree, and have the end user re-libtoolize if building from source. In fact my new build system requires us to delete the existing libtool and re-libtoolize at build time (new build system takes care of re-libtoolizing). If we delete the directory now, I need to drop the new build system in then to make sure we build at all. Re-libtoolizing with 1.5.22 should fix the problems on OSX.

The new build system is being setup to handle cross compliation, the original scripts fail at that with intresting errors (such as building x86 assembler if the build system is x86, but the target is powerpc)

I've also been writing new compiling instructions to go with the new build system, there are general instructions, plus specfic instructions for each system it bas been built on eg Ubuntu, Nexenta, MinGW etc

DaniJ

<blockquote>OK. The removal of Doomsday.wad broke the linux (autotools) build scripts. I don't see the Doomsday.pk3 file that is meant to replace it, is that not implemeneted yet ?</blockquote>
Doomsday.PK3 should be built automatically to include the contents of the following folders keeping this virtual folder structure:
Data/Fonts
Data/Graphics
Data/KeyMaps

CPHelp.txt SHOULD be included in Doomsday.PK3 but currently it is parsed before the virtual file system is intialized so it cannot be yet.

skyjake

I think we can make the Beta 4 release on Sunday. There is no point in rushing in a new build system in that timeframe.

<blockquote>Skyjake, I see notes in the source that libtool is broken on OSX. the version of libtool we bundle is rather old (and has security issues). We should remove it from the source tree, and have the end user re-libtoolize if building from source</blockquote>Yes, we should not bundle a libtool with the sources.
<blockquote>Re-libtoolizing with 1.5.22 should fix the problems on OSX.</blockquote> However, ltdl/libtool are not used on OS X at the moment, only on Linux/Unix. I am using the native dlopen/dlsym implementation (from dlfcn.h) as provided by Apple. I am not too keen on addressing this particular issue at this time, as the current code is working perfectly. Also, on OS X the plugins are in a bundle format, which forces us to use a different loading code anyway.
<blockquote>The new build system is being setup to handle cross compliation</blockquote>Sounds cool, although I wonder if it can really be accomplished in practice. Particularly compiling PPC binaries in a non-Mac environment sounds like a difficult task, since the Apple-provided frameworks (e.g., OpenGL.framework, QuickTime.framework, Cocoa.framework) and system libraries are missing.

Yagisan

I've adjusted the build system to cope with the fact that Doomsday.wad no longer exists. It however does not build a Doomsday.pk3, due to a missunderstanding on my part, I will not be able to add the functionality of zipping up Data/Fonts, Data/Graphics and Data/KeyMaps by Sunday (some 22 hours away). The contents of those directories have been installed unziped, into the real filesystem. Deng works with this, so it can be released without it. If Doomsday.pk3 is vitally important to be released I'll zip the directories, and then inject it into svn.

<blockquote>However, ltdl/libtool are not used on OS X at the moment, only on Linux/Unix. I am using the native dlopen/dlsym implementation (from dlfcn.h) as provided by Apple. I am not too keen on addressing this particular issue at this time, as the current code is working perfectly. Also, on OS X the plugins are in a bundle format, which forces us to use a different loading code anyway.</blockquote> Fair enough. We'll revisit it at a later stage

<blockquote>sounds cool, although I wonder if it can really be accomplished in practice. Particularly compiling PPC binaries in a non-Mac environment sounds like a difficult task, since the Apple-provided frameworks (e.g., OpenGL.framework, QuickTime.framework, Cocoa.framework) and system libraries are missing.</blockquote>It can be done. Initial cross compile target is actually expected to be different architecture linux systems, then most likely windows binaries built on *.NIX. In any case, I'd enjoy the challange, and it scratches my itch.

Yagisan

Quickly hacked in support for generating Doomsday.pk3, and for regenerating dd_maptypes.h and p_maptypes.h at build time. More elegant solution post beta4.