Linux Build Notes

[ikrabbe]

Linux Development

1. 
   
   
2. Build Notes
   I want to collect some Linux Build and development topics in this thread. Feel free to answer with your opinions, but you don't need to help out really, as I will work through the bugs myself, pretty likely.
   First let me state that I'm slightly unhappy with the build system, maybe because I haven't found much documentation and reference about it. But on the other hand it works quite straight through the code, so not much documentation is needed right now.
   Though I stumbled over a small problem, not having installed the enet package on my system. I'm going to fix that today, but having this in mind I think there should be something as a sysem feature detector, as autoconf does, as the linux systems out there differ quite much, as you might have experienced already.
   Anything in here is based on the 0ad-9999.ebuild.
   1. 
      
      
   2. ENet: To solve custom ENet dependencies (if you installed enet in a uncommon place), we should write a function that makes up include and library paths based on pkg-config.
      
      As a last resort there should be an easy way to configure a custom paths for Enet and possibly for the other dependent packages too.
      
      
      
      
   3. Some General Remarks:
      
      General: Let's collect all dependencies. Not all are needed by anyone, so possibly a split up of the repository stripped of all external dependencies should help.
      
      
      SCM(Source Control Management): Yes SVN is not the best selection. Choose
      git
      and be happy. I will always assist you with in moving to git.
      
      
      Communication: How about to open a IRC Chat (#0ad on freenode?!)?
      
      
      
      

BTW: It might help to give me a trac key. I might send an application in some days.
--
A more cool signature is about to come...

For any Users of the famous VI Editor and firefox (not too uncommon I think): Try the Firefox Vimperator Plugin ! There's no cooler tool to edit forums and browse the net. Also usefull for anyone else who hates these javascript editors to edit Forum posts.
Try it and feel free. BTW: As I found it I just searched for a way to browse the net without menu bars, tab bars, scrollbars and status lines. And it just works!

Edited May 3, 2010 by ikrabbe

[Ykkrosh]

Though I stumbled over a small problem, not having installed the enet package on my system. I'm going to fix that today, but having this in mind I think there should be something as a sysem feature detector, as autoconf does, as the linux systems out there differ quite much, as you might have experienced already.

I think it's worked surprisingly well so far, but I agree it's far from ideal. There have been various discussions about changing the build system (upgrading to Premake 4, or switching to CMake), but as far as I'm aware there hasn't been any real work on that yet.

Anything in here is based on the 0ad-9999.ebuild

If you're using a Gentoo ebuild then dependencies ought to be handled automatically - why are you having problems with enet?

To solve custom ENet dependencies (if you installed enet in a uncommon place), we should write a function that makes up include and library paths based on pkg-config.

According to a comment in build/premake/extern_libs.lua (and here), pkg-config breaks with enet on Ubuntu. Looks like it's fixed in the package in Lucid but not in Karmic. Gentoo doesn't set up pkg-config for enet at all. I don't know if there's an easy way to avoid these problems - otherwise it looks like it will cause more issues than it solves.

As a last resort there should be an easy way to configure a custom paths for Enet and possibly for the other dependent packages too.

Yeah, currently the only way to add extra include/lib paths is by hacking the .lua files, which isn't good.

General: Let's collect all dependencies. Not all are needed by anyone, so possibly a split up of the repository stripped of all external dependencies should help.

Not quite sure what you mean - the build instructions already list the dependencies, and commands to install them on various Linux distros, which seems the best we can do.

SCM(Source Control Management): Yes SVN is not the best selection. Choose git and be happy. I will always assist you with in moving to git.

I've got an occasionally-updated Hg repository with a mirror of the source code from SVN, but completely replacing SVN would be hard since we use it for lots of binary files (including the large precompiled Windows .exes which add up to many hundreds of MB over the repository history) and for lots of work-in-progress non-public files, so we'd need some wider changes to make everything work with a new source control system. SVN isn't great for the source code, but splitting things across two repositories would make it harder for everyone. So it's not clear to me what would be a good solution

Communication: How about to open a IRC Chat (#0ad on freenode?!)?

We use #0ad on Quakenet (for historical reasons).

BTW: It might help to give me a trac key.

You can register yourself

[ikrabbe]

If I'm not too lazy next week I will try to understand your pathfinder algorithms and may be able to add something usefull there, lets see. Now I will stay with a small reply:

I think it's worked surprisingly well so far, but I agree it's far from ideal. There have been various discussions about changing the build system (upgrading to Premake 4, or switching to CMake), but as far as I'm aware there hasn't been any real work on that yet.

Actually after working through the build process I think it's simple enough to keep it as it is. Lua is a cool new language. We just need to add some configuration logic.

If you're using a Gentoo ebuild then dependencies ought to be handled automatically - why are you having problems with enet?

According to a comment in build/premake/extern_libs.lua (and here), pkg-config breaks with enet on Ubuntu. Looks like it's fixed in the package in Lucid but not in Karmic. Gentoo doesn't set up pkg-config for enet at all. I don't know if there's an easy way to avoid these problems - otherwise it looks like it will cause more issues than it solves.

This ENet is a quite strange and very small package (just compiling into a quite small static library). In gentoo it is instlled in a standard location, so it will just be found in /usr/lib and /usr/include without extra parameters.

Anyway, my forum post was a fast shot. I managed to use the ebuild and build the game. I first used the ebuild directly which diverted me from dependency checking.

Yeah, currently the only way to add extra include/lib paths is by hacking the .lua files, which isn't good.

Not quite sure what you mean - the build instructions already list the dependencies, and commands to install them on various Linux distros, which seems the best we can do.

Currently the lua files are simple enough to edit. But there should one or two standard methods described how to edit the lua build files and how to add a new module for example. That will make project development easier. I will try to add something usefull into the trac wiki, to make clear what I want. But it might take me some weeks to take the time for it.

I've got an occasionally-updated Hg repository with a mirror of the source code from SVN, but completely replacing SVN would be hard since we use it for lots of binary files (including the large precompiled Windows .exes which add up to many hundreds of MB over the repository history) and for lots of work-in-progress non-public files, so we'd need some wider changes to make everything work with a new source control system. SVN isn't great for the source code, but splitting things across two repositories would make it harder for everyone. So it's not clear to me what would be a good solution

I think it would be best to split the binaries and the sourcecode into different repositories. Still I would vote for git when you restructure the repository. But what is a good solution? If you want a repository that you checkout, and make install afterwards, I don't think there is a "good" solution.

You finally have to split things up and branch out. That will become impossible to handle with subversion, when the project grows.

We use #0ad on Quakenet (for historical reasons).

That's cool.

You can register yourself

That's even cooler. Good Job.

Maybe such a discussion should go into a wiki page then