distribution of el

[Malaclypse]

Hi,

 

I think, current way of distributing EL needs a bit more support. I have the following ideas

about this topic. I put this in programming, because I think it's best placed here. If

you think different, please move to the appropriate place

 

As I already implemented a configure script for the client, what do you think of extending this

to the whole project? Autoconf/automake works on almost any platform, including windows if you

have cygwin or mingw installed. This could enable us an uniform building process, largely

independant of the underlying platform, as long as the platform itself is supported by el.

And we can enable/disable building of components, like mapeditor using command line parameters

to configure.

 

The package maintainer, that is the person who build packages and distributes them for other

people to download, will have to setup a particular directory layout, with an el root directory,

containing several subdirectories for client and mapeditor sources, game data and probably other

stuff, like gtk elconfig client from wytter. This el root directory will contain the configure

script. We need to provide a script for maintainance purposes, which will bring all files

in sync with the requested release tag. We need to ensure proper tagging of all files for

releases. AFAIK the current sources are not tagged for the 1.0.1 release, only for the 1.0.0

release, but files have already been added to cvs that are targeted at 1.0.2 release.

 

Requirements for the packagers machine would be:

• GNU make
  
• GNU autoconf
  
• GNU automake
  
• gcc
  
• cvs client of your choice
  
• bash or similar shell, also cygwin shell
  

After configuring the built will be done by a simple 'make dist', which will compile

any necessary targets, installs them into a virtual root and packages them together into an

archive. Those packages will be platform dependant and would contain only the files needed,

that is no el.x86.linux.bin on windows and no el.exe and *.dll files on other platforms.

 

This is only a very general setup for binary distribution, but can be implemented for

virtually any platform we are interested in. One step further, would be to provide

packages that are more on the needs of various platforms, like a windows installer,

rpm and deb packages, and general purpose tar archives, as well as additional support

for source distributions, like Gentoo (which is already supported quite well).

 

What do you think of this? It's only a rough picture, but I hope you got it Didn't want

to make the post too long

[Grum]

Rough? I think it goes into great detail. Anyway, I think one of the first things to do, is to set up this directory structure, and to put the game data, including models and other art, in CVS. That is, if Roja and Ent can live with that. Source code should go in a src/ subdirectory, I think. We should try to set it up such that he complete game can be downloaded with a single cvs command.

[Malaclypse]

I didn't thought on making the directory structure within cvs. This is of course, a nice feature, but I tend to keep away from moving projects within cvs (don't know enough about cvs, if someone else can do this ), that's why I came up with a script gathering all the needed files from the different cvs hosts and setting up the initial build structure.

 

I agree with the src/ subdir. This should contain the directories for the client and for the mapeditor as well. Also other sources will eventually got here, like the elconfig, I mentioned. Then there should be a directory for game data, which will be the root of all data files. The directory structure of those files, will get copied verbatim during the installation.

[mihaim]

Few observations (correct me if i'm wrong):

- The art files , models and such can't be added to CVS becasue it will break the

berlios license agreement ( these files are not opensource )

- Putting the art files on a CVS has both advantages and disadvantages. Not all the users should have access to all the art files ( it will spoil the fun for the new objects added) . A compromise would be a private CVS server for developers ( Yes this means that if someone wants to help in this field he will have to contact the project manager to get an account ) .

 

Reagarding the multiplatform uniform building system ... It's a verry beautifull ideea but this if is not well taken care can fail horibbly.

We have 2 major platforms for ELC: Unix and Windows .

First let's make a document (an step by step HOWTO) on what tools are needed to start the development in this direction ( where we get the tools , how to install on linux, how to install on windows ). After this step is done we can move to step 2 and create the configure scripts.

[Malaclypse]

I think the idea with the private cvs server would be quite good. I already thought that something may be the case.

 

We could also use a package of the data, downloadable from some server, but I think, the data needs to be reviewed. For example, the languages subdir now resides within the game data zip file, but the actor_defs directory and xml files, are part of the client source. There is atm some mixing of files, and it should be reviewed to where they belong and moved appropriately.

 

I will provide a howto on requirements and installation of tools later. I know that this can work on windows, if there is either cygwin or mingw installed, but I don't have access to a windows developer machine, and I am not aware of native possibilities for windows.

[Entropy]

I don't think it's a good idea to put the datafiles in the CVS. The CVS is not for datafiles, it's for code and some ascii files.

FTP and HTTPs are for files.

[Malaclypse]

Ok, so we will use a pre-packaged archive like it is now and simply download this.

 

What about the files, I mentioned? Imho either the actor_defs dir should be moved to the game data archive, or the languages subdirectory of the data should be moved to the source code (including encyclopedia). I prefer the second way, as first they're text files, and I think they belong very close to the client itself. For distribution itself, it won't matter much though.

 

What do you think about this?

[Grum]

I think the encyclopedia should be moved into cvs, as its update relatively often.

[Entropy]

The CVS should be only for code, and the files that were introduce since the last update, and make the game not working without them (such as the actors defs).

Also, I don't want the make/install thingy to use the last CVS version, because it can be unstable. Rather, it should use the released version source code.

[Malaclypse]

I do not fully agree with you here, Entropy. I think cvs should be for any files, that may change much, but where it is necessary to cover several different versions. It is mostly used for source code, but not solely. I would also prefer to move the encyclopedia and language stuff to cvs, because they are directly involved with the development (internationalizing the client for example). I just think it's somehow incosistent to have some of those files within cvs, and the others within the game data.

 

And I didn't say that it should use the latest cvs source code, but instead it should use a version, that is supported at configuration time. That is, it will download the release which has a specified release tag assigned. That's why we need to ensure, files in cvs are properly tagged.

[Malaclypse]

Ok, here's the howto

 

 

Requirements and setup of the GNU autotools suite

 

I will cover the main supported architectures, that is windows and linux each separately. As I don't have access to a windows machine, some of this is based on reminders I have, how it once was

 

I will update this post as needed.

 

For convenience I will repeat the general requirements here:

• GNU make
  
• GNU autoconf
  
• GNU automake
  
• gcc
  
• cvs
  

Additionally a shell, preferrably a SH-style shell is needed. See below for details.

 

As your individual setup may vary on a large variety, both on linux as well as on windows, I will assume, you have nothing installed, that is, I will start with a end user desktop system without any development tools installed. I am sure, that if you already have parts of it installed (for example you already have a full or partial working development environment) you will figure out the necessary steps from the detailed instructions below.

 

 

First I will cover setup on linux.

 

*Shall I cover different package formats separately here?

 

 

I assume that your system uses some sort of package manager, that is capable of handling package requirements itself[1]. Install the following packages in this order:

• make
  gcc
  autoconf
  automake
  cvs
  

This should also install perl and m4 on your system, if they're not installed already, as they are required by the autotools. If your package manager also offers the installation of development packages (like for example gcc-devel for some rpm systems) install them as well for any of the above packages (this might not be necessary anywhere, or only for some of the packages, but it doesn't harm to install them all).

 

Most linux distributions come with bash as default shell. This is quite good for our purpose. If you use another shell, for example a c-style shell like csh or tcsh please ensure you have bash (or another sh-style shell) installed too. The configure script we use, is actually a sh shell script.

 

Well this should've been all to setup. Normally no additional configuration is necessary here. Verify a working environment, by issuing the following commands:

lancelot@gwenhwyfar elc $ make --version
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

lancelot@gwenhwyfar elc $ autoconf --version
autoconf (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

lancelot@gwenhwyfar elc $ automake --version
automake (GNU automake) 1.9.4
Written by Tom Tromey <tromey@redhat.com>.
Copyright 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

lancelot@gwenhwyfar elc $ gcc --version
gcc (GCC) 3.3.5  (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)
Copyright © 2003 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für VERKAUFBARKEIT oder FÜR SPEZIELLE ZWECKE.

lancelot@gwenhwyfar elc $ cvs --version
Concurrent Versions System (CVS) 1.11.18 (client/server)
Copyright (c) 1989-2004 Brian Berliner, david d `zoo' zuhn, 
                       Jeff Polk, and other authors
CVS may be copied only under the terms of the GNU General Public License,
a copy of which can be found with the CVS distribution kit.
Specify the --help option for further information about CVS

The version numbers are not important at the moment. If you use one of the latest stable releases should work fine.

 

 

 

Installation on windows can be done in several ways. There are at least two ways, which should be quite similar. One is using cygwin, the other is using mingw. As I personally have never used mingw, I can not cover it here. If someone else has experience in using it, feel free to add to this.

 

Download the cygwin setup file from http://www.cygwin.com. I'm sorry I can't provide an exact location atm, but the servers seems down. At least I can't reach it atm .

 

After downloading execute the setup. It comes with a wizard like interface. At one page, you can select the packages, that should be installed additionally. This covers a wide range of GNU tools, that provide virtually any GNU software available on unix systems to windows os. Be sure, that you check autoconf, automake, gcc and make. You don't need to check a cvs client (don't even know if one is provided), because in general you will use one the cvs GUI clients for windows. Cygwin itself comes with a bash shell, that is executed whenever you run cygwin. The cygwin installer should cover all requirements automatically, so there should be no need to install any additional packages.

 

After installation succeeds, you should be able to start cygwin. Open it, a shell window will come up, and you are in a bash shell environment. Issue the same sequence of commands as in the description for linux (look at the code section above). Anything should now be setup and work properly.

 

 

 

 

Ok, so far. I hope I didn't forgot too much Please give me feedback. What did I miss, what is unclear or vague? Any questions, comments, flames?

 

 

 

[1]If this is not the case, keep in mind that both autoconf and automake require perl and m4 installed on your system.

[Aitrus]

Hi, i may not undstand much about what you are all talking about but i know a good distributor called Red ant which distributes games from unknown developers for a minimal fee, if you can get the game to a stage where it is marketable im sure you can get them, they distribute games such as planetside and Auron games, hell most of my new games are red ant xD (they also do a bargain bin type thing where they sell games for $10-20)

[crusadingknight]

Hi, i may not undstand much about what you are all talking about but i know a good distributor called Red ant which distributes games from unknown developers for a minimal fee, if you can get the game to a stage where it is marketable im sure you can get them, they distribute games such as planetside and Auron games, hell most of my new games are red ant xD (they also do a bargain bin type thing where they sell games for $10-20)

Erm, they're talking about the client cvs being autobuilt... distributors can't help with that.

[Malaclypse]

Aitrus this thread is about creating a distributable package from the source code and the data, not about actually distributing it.