Few use{ful/less} comments on current GNU/Linux build procedure

[Khaos]

Few miscellaneous comments on the current GNU/Linux build procedure. Aimed at TFS developers, most others don't really have to look here too much.

TFS developers please read this. It's long but it may be useful to know what (picky) GNU/Linux users want. Pay special attention to a suggestion marked in green on the bottom of the post. Thank you.

1) No autotools requiring manual Makefile modification.
Theoretically this would be cool. And I would really really like it few months ago. In practice, this makes user have to edit the Makefile to turn off e.g. MySQL support (due to not having the libraries or simply not wanting to use MySQL) and the user has to edit this in several places. This also causes several problems as outlined below.
So it would be cool if autotools would be used.

2) In target "all", clean is called.
Target all is traditionally used to call all targets necessary for compiling the executable. It is not used for first cleaning and then building all over; use a separate target for that, named e.g. "rebuild".
I believe I know why you did this. Because if you changed headers, you wanted all .cpp-based object files that use those headers to be changed. Well, that's what autotools would automagically solve for you -- the dependency calculation. So even if I change just one line in a .cpp file, I have to wait for a full rebuild. That's bad -- I don't have an ubermachine.
In the default released target, please don't depend on the "clean" target when building the executable.

3) Target producing executable does not have same name as executable.
This is bad because whenever I call make, linker will link the executable again (even if additional targets are mentioned in the meantime). Make uses timestamps of object files compared to timestamp of file called like the target name. Thus, the system depends on having produced filename being called the same as the target name.
Please rename the target "theforgottenserver" to "TheForgottenServer" to ensure the linker is not called every time when make-ing, even if linking is not necessary.

4) No autotools == harder distribution
It's really easy to make a .tar.gz for distribution when using autotools:

$ make dist

Also you can easily test if the resulting package can produce executable:

$ make distcheck

5) No autotools == harder building of Linux distro packages (.deb, .rpm, ...)
Debian packaging system really really likes it if you provide it with a simple configurable build system, e.g. autotools based. While it can actually run any set of commands (so, if you correctly produce package command set, it can also use a plain Makefile and I'm sure many Debian packages do) -- I really recommend you use autotools.
Why?
Debian really wants you to provide "pristine" original .tar.gz from the package release, and then separately provide a patched directory from which it can produce a .diff patchset (for their own sick and twisted purposes). So you again need a .tar.gz you can easily produce and distribute. While it is certainly possible to manually pack up a tarball, it'd be good that a prospective Debian packager also can easily produce a tarball from your SVN sources in case you don't make a release in several months.


So as you can see, most of my complaints is because you don't use Autotools.

If any of the TFS developers wants any hints on how to produce Autotools definition files, take a look at YATC's "configure.ac" and "Makefile.am", I believe we hacked them well enough. (Note that they're still a hack.)
We still don't use config.h but I didn't think that using autotools correctly is atm of great priority.


Side notes unrelated to build system
1) Why, oh why do you abuse Subversion just to make releases? Why don't you use it for its primary purpose: collaboration and version tracking!? Perhaps you already do, locally. But if developing under a free software license for an open source community, I don't see why you should develop behind closed doors. To prevent someone from stealing your ideas early, before you make a public release? No need to worry on that.

2) OMG NOT A COMPLAINT!
Actually a suggestion!

Apparently the upstream OpenTibia team has slowed down the development and is complicating with the release (they now don't want to bother with releasing 0.6.0 from trunk and instead concentrated on avesta; whatever).
You seem to be more user-oriented and you seem to be intent on forking from OpenTibia (actually you already did since you didn't transition to revdbsys). Overall this could be a positive thing.

Could you please take a look at Linux Filesystem Hierarchy Standard? That's the arrangement of files that Debian wants. So could you provide a macro option for defining that TFS uses FHS? I'd be really happy if you did that.

Why?

Because I want to produce Debian packages for an OpenTibia(-based) server. I wanted to do upstream OtServ package, but since OtServ seems to be in a development hell and I don't have anyone left to spam with regards to this (and I'm unwilling to dirty my hands that deep) -- could you adapt that?

I can also provide hints on what should go where, in this thread. Sadly it's too late and I have to go to sleep (getting up early) so I don't have will or time to go through FHS and TFS hierarchy to make suggestions. But I'd still like your consideration and feedback if you want to do this.


Disclaimer.
This may be boring and repetitive and already discussed on these boards. I did a quick search on "Makefile" and didn't seem to find anything interesting. So ... if I'm annoying, please consider this again and only then tell me I'm annoying; I may have actually said something smart (wouldn't be the first time ... I hope).

 

[Kiper]

I really see autotools missing as big failure too. I don't have Linux/GNU machine to work on. Also my knownledge about autotools is zero. These comments are really constructive also I like that you actually liked TFS. About svn, too many users was using unstable version from svn and it was one big mess on the forum because they reported bugs here so we decided to switch to private one.

Note: 0.3 version include revdbsys.

 

[Mark]

I'm using Debian Sid GNU/Linux on my laptop at the moment (I also have Etch on my server computer), but my knowledge about autotools is zero aswell. I'll see if I can find time to read the autotools files in OpenTibia/YATC and try to understand how it works.

EDIT: I've added autotools to TFS 0.3 now, they're pretty much based on the OTServ files but with modifications to make it more userfriendly and to fit TFS sourcecode.

Regarding FHS, would this:

/usr/bin/theforgottenserver
/usr/share/doc/theforgottenserver/
/etc/theforgottenserver/config.lua [I](perhaps this should go in ~/.theforgottenserver/config.lua or we could check if ~/.theforgottenserver/config.lua exists before using /etc/theforgottenserver/config.lua)[/I]
/var/theforgottenserver/data/ [I](this would be default, then we'll add datadir back to config.lua if someone wants to run more than one server on same computer with different data)[/I]
/var/log/theforgottenserver/client_assertions.txt
/var/log/theforgottenserver/<playername> bugreport.txt

.. be the correct structure?

 

[Khaos]

Hi,

thanks for the attention to my post

I think this would be just a tiny bit better:

/usr/[COLOR="Red"][B]sbin[/B][/COLOR]/tfs
/usr/share/doc/tfs/ -- i'll be filling this doc when i make deb packages, the software itself shouldnt depend on it
/etc/tfs/config.lua (check if ~/.tfs/config.lua exists before using /etc/tfs/config.lua - [I]i agree with this option[/I])
/usr/share/tfs/ -- for static data such as map, npc data, ...
/var/lib/tfs/  -- for dynamic data such as sqlite database
/var/log/tfs/client_assertions.txt
/var/log/tfsplayername>[b][u][COLOR="Red"]_[/COLOR][/u][/b]bugreport.txt

I suggest shortening to TFS unless there already is a package called TFS in Debian

I removed the space from <playername>_bugreport.txt and put an underscore.

Servers are usually placed in sbin because they are usually started by the root (servers are not very user-specific stuff). Besides, normal user can type "/usr/sbin/tfs" anyways, instead of just typing "tfs" which would be reserved for root.

Not only this, I'd make an "/etc/init.d" script for autostarting the server at startup. Only thing that should be added id "-d" command line option which would daemonize the server (send it into background). It's usually done with fork(). If you want I can perhaps apply this modification.

 

[Kiper]

Implemented FHS to TFS today, it is on private svn. Still need to be tested. Also it could be adapted to otserv.

 

[Master-m]

Damn I would love to see those things also. I work much in linux on my work lately, So I think I'm going to switch to debian at home also.

I think that the private svn is better to prevent the so called "noobies" from getting major error and spamming it here on the forums.
But now others can't work with it also. Maybe you can make an page where the user needs to agree to continue and it contains something like "If you want to use it, use it as your own risk. This is not verified as stable, do not report/complain about it."

 

[Khaos]

Kiper,

could you upload a passworded .rar somewhere and give me link + password to test? That would be most appreciated, I've studied FHS and Debian docs when I was making some .deb packages.

Btw the repo, besides YATC, includes Cip's Tibia and TibiaWine, adapted for FHS and with appropriate shell scripts included. Cip's packages were not tested and need 3rd party testing, I'd appreciate feedback.

Also, do you plan on really implementing FHS on upstream OpenTibia? If so, feel free to patch Avesta, punch in "svn diff" and I'll commit that, with appropriate credits to you and whoever else works on that (credits in the SVN log, I'm not sure I can do much more). I wanted to do it for quite some time, but I never felt like digging deep into the code

 

[Kiper]

Actually it wasn't very big code digging, just some lines.