0.3

[Z-Man]

I don't know, you're the release manager for this one Re-tagging could provoke the anger of Mr. Subversion History. What I'd do is just do a build from the revision you gave from the trunk, without the tag, let the QA Team test that, and if it's all right, then tag that revision, rebuild and release. It's more work (one more build to do), but less SVN management trouble.

Anyway, the release process doesn't work The build process isn't updated to Joda's rearrangements yet. The windows source zip as we build it doesn't contain the win32 folder, because it's not in the tarball (missing from EXTRADIST) and the extra zip creation script doesn't know about it, it's still looking for the contents ../build_codeblocks. So I'll first have to fix that before we can build. It'll have to wait some hours, I'll ping when it's done.

[Lucifer]

Ummm, hm. Ok, since I'm the Release Manager for this, here's what I say. We have to have joda's work assimilated for this release, I suspect that's why he was doing it. Even if not, I think it should be done for this one. Sooooo, if it's going to be done in the next day (30 hours or so to accomodate everyone's day), then your plan works. If not, we should branch to finish it and release from the branch in a few days when it's done. Of course, at the point a branch is made, what happens next is pretty obvious, right?

Umm, I guess I would have paid more attention to the build scripts if I'd have known earlier (as in a month ago at least) that you wanted someone else to be release engineer for this one. Last time I fooled with them, which was way back when I was running Mandriva, the build scripts didn't work well for me, and I've kinda assumed they still work really well for you but are mostly untested for the rest of us. If you don't mind (doesn't look like you mind), I think we should probably put on our list for 0.3.1 having several of us other developers test and possibly adjust the build scripts on our systems. I like the idea of being able to switch out release engineers on the fly, but I don't know if we're anywhere near it. Seriously, I don't know, maybe we're already there, I just don't know.

I think we should set as a goal for sometime around 0.3.3, maybe 0.3.4 (earlier if it happens) being able to do Windows and autopackage from the same command (make release or whatever you've got in there already), and I'd probably want to throw on rpm and deb. I know, we can't exactly anticipate that the same machine will be able to build and link against libraries that work on any given rpm and deb machine, but it's worth having in the automation part anyway. AFAIK, the only real change besides just testing the build scripts, that's needed is getting make install to setup a directory structure that nsis expects for building the installer, and of course getting it to cross-compile in the first place.

[Z-Man]

The tarball and zip building should work for everyone. For the autopackage, you need the autopackage SDK and a apgcc-compiled version of libxml2 and FTGL (the README in build/autopackage tells you how to make them), it shouldn't depend on any other system specific thing. The RPM build is more difficult, the RPM tools are a bit more picky about their environment, and even more so the debian stuff. The deb build refuses to start for me because it thinks I'm missing the dependencies, so it and the mandriva RPM are probably hopelessly outdated.

[Z-Man]

Another build problem: libxml2-2.6.0 doesn't work any more. That's what I used for the 64 bit server build, because static linking doesn't work there for some reason unless I link with a regular libxml2 build, no apgcc, which then depends on a current version of glibc. There are three possible ways to proceed here:

- Fix the problem, make it build with 2.6.0
- Build a statically linked 64 bit server that depends on current glibc (that's what I did for the client all the time)
- Don't build a 64 bit server.

It's a release manager decision

[Z-Man]

I guess the decision has made itself No 64 bit server build, unless we take more time and branch. I tried to fix the libxml2 2.6.0 problem (wasn't hard), but linking fails with this:

Code: Select all

apg++  -I. -I.. -O0 -g -Wno-long-long   -o armagetronad_main  armagetronad_main-gFloor.o libtron.a libengine.a libnetwork.a libui.a thirdparty/shttpd/libshttpd.a librender.a libtools.a  -lpthread -L/home/moos/usr/lib -lxml2 -lz -lm
thirdparty/shttpd/libshttpd.a(libshttpd_a-shttpd.o)(.text+0x673): In function `casecmp':
../../../../../armagetronad/src/thirdparty/shttpd/shttpd.c:778: undefined reference to `__ctype_tolower@GLIBC_2.0'
thirdparty/shttpd/libshttpd.a(libshttpd_a-shttpd.o)(.text+0x6d5): In function `ncasecmp':
../../../../../armagetronad/src/thirdparty/shttpd/shttpd.c:793: undefined reference to `__ctype_tolower@GLIBC_2.0'
thirdparty/shttpd/libshttpd.a(libshttpd_a-shttpd.o)(.text+0x743):../../../../../armagetronad/src/thirdparty/shttpd/shttpd.c:793: undefined reference to `__ctype_tolower@GLIBC_2.0'
thirdparty/shttpd/libshttpd.a(libshttpd_a-shttpd.o)(.text+0x1023): In function `getreqlen':
../../../../../armagetronad/src/thirdparty/shttpd/shttpd.c:1185: undefined reference to `__ctype_b@GLIBC_2.0'
thirdparty/shttpd/libshttpd.a(libshttpd_a-shttpd.o)(.text+0x1c28): In function `urldecode':
../../../../../armagetronad/src/thirdparty/shttpd/shttpd.c:1552: undefined reference to `__ctype_b@GLIBC_2.0'
thirdparty/shttpd/libshttpd.a(libshttpd_a-shttpd.o)(.text+0x1c4d):../../../../../armagetronad/src/thirdparty/shttpd/shttpd.c:1547: undefined reference to `__ctype_tolower@GLIBC_2.0'
thirdparty/shttpd/libshttpd.a(libshttpd_a-shttpd.o)(.text+0x37b6): In function `spawncgi':
../../../../../armagetronad/src/thirdparty/shttpd/shttpd.c:2331: undefined reference to `__ctype_toupper@GLIBC_2.0'

Maybe the fact that shttpd.c is our only plain C file is responsible. I quickly tried to compile it as a C++ file, but there were lots of illegal pointer casts we'd have to fix first. That, or investigating the true cause of the linker problems, can't be done today.

[joda.bot]

ok, just tell me what to do ? I've been in bed all weekend, because of my illness, but I hope I can help you complete the build preparations.

[Z-Man]

Nothing yet I have the hope that I can build the Windows version myself, the last time I only had to rearrange the projects in the Code::Blocks workspace becasue my version doesn't support dependencies yet.

[Lucifer]

How badly do we need 0.3 for 64bit x86? Also, how soon before we have python? I seem to recall you were going to start a branch to do the gGame refactoring and add some small python integration as part of it. I will be happy to replace shttpd with a python webserver when that happens, and if it's going to happen for 0.3.1 or 0.3.2, I'd just as soon leave the 64bit release until then. It's a development series, some backsliding is allowed right now, right?

But if not, then we can either delay 0.3.0 and fix shttpd, or fix it for 0.3.1. I'm inclined to fix it for 0.3.1, which means you need do nothing now about it.

(I haven't been terribly happy with shttpd since sticking it in there. It's really nice, don't get me wrong, but the level of customization I want is quite a bit of work compared to having it in python instead)

[Z-Man]

I would not rate it as that important. Building from source still works, and I expect a server admin to be capable of that.

The Windows build is making problems now Seems our cross compilation experiments broke Code::Blocks compilation. I can take care of that.

[k]

Nothing yet I have the hope that I can build the Windows version myself, the last time I only had to rearrange the projects in the Code::Blocks workspace becasue my version doesn't support dependencies yet.

The nightly builds of Code::Blocks support project dependencies. I just started playing with the nightlies since they have support for building projects from the command line.

The Windows build is making problems now Seems our cross compilation experiments broke Code::Blocks compilation. I can take care of that.

I'm guessing this is why I can't build the trunk.

[Lucifer]

Yeah, I don't know if we can check for mingw within code::blocks separately from mingw as a cross-compiler. It shouldn't make a difference, should it? But id does...

Ummm, any objections to having a configure flag like --enable-crossbuild ? Then we can just use our own #define to deal with the problem and let K and Joda keep doing what they're doing.

[Z-Man]

I'm stuck with the Windows stuff. The build works fine, and Joda's makedist.bat works as well. But how is the installer supposed to work?

[k]

Assuming this is what you are asking... I'm not sure how they are supposed to work now, but you used to have to copy the .nsi files, banner.* files, and Armagetron Forums url from the VisualC directory to the dist/ directory and run the nsi files from there. Of course they won't finish building the installation files because the generated documentation doesn't exist so it needs to be copied from the *nix build or an existing installation to the dist/ directory. I am still slowly getting things back together for nightly builds so I'm not sure if anything else needs to be done with the latest code base to get installations created again.

Edit: Looks like Joda has copied all the installation files over to the win32 directory and makedist is copying them to the build directories.

[Z-Man]

I know how it used to work, thanks And that's the way it still works in the 0.2.8 branch. But on the Trunk, there have been rearrangements.

The situation seems under control now, we've handled it on IRC. I'm currently using revision 4872 to do an alpha build.

Edit: no, I'm not. I'm getting
windres.exe: armagetron.rc:70 syntax error.
when building from the zip, could be an encoding conversion error. Lucifer: please branch the whole armagetronad hierarchy with winlibs, build and armagetronad at least. I'm not getting this done today, and have little time tomorrow.

Edit^2: no conversion error, a vanilla MAJOR_VERSION is still stuck there. I've got to do more adaptions to the source zip creation.

[Z-Man]

After some tweaking in the build module, the Windows build now works cleanly from the source zip. The results are on aabeta:

http://beta.armagetronad.net/?product=client&branch=0.3

Luke: what is the correct way to handle the branch? It doesn't appear in the dropdown list automatically, so I added it to releases_filter. I'm for labeling it 0.3, not Devel, to keep it apart from 1.1.