Sign in to follow this  
Lighta

Upd Makefile and shell

Recommended Posts

Hi so this is a suggestion to update our environnement.

I'll talk about :

1) Main dir hirarchie and files in

2) Makefiles

3) Shell script update

 

You'll need a basic knowledge on Make (Makefile), shell, and unix filesystem to understand the following.

here the current diff :

http://upaste.me/b5405421f849ddda

 

1) I'm thinking the main dir is kinda ugly with a bunch of file we don't use. (we don't use .bat and .sh in same time nor all .sln solution);
I'd like to move each .sln into their project path and make a script folder for the (.sh .bat).

Wich is more a less the same things as 'tools' dir atm, but I think a rename could be more disanbuisious and we could add more in their.

Goal would be to cleanup thing a bit and to create a package/systeme rather then 1 prog like we tend to do atm with increasing map-serv while we could do other proc.

 

2) Makefiles

So just a reminder of the current flow : configure.in is used with autoconf to produce configure, configure is used to produce Makefile by reading Makefile.in and finally make use those makefile to produce binary.

 

With a quick look on Makefiles I saw we still had some 'txt' target in some place (src/map) wich had invalid target and therefore can't compile. You may have a binary with some few edit but it will most likely crash due to all the function require mysql. Therefor I think a small cleanup and harmonisation between those Makefile are necessary to prevent any of this attemp and to not have ugly Makefile harder to maintain.

Also I'm not sure about the extensive check on mysql, sure it prevent compiling if you don't have the requirement by default but that would mean your ./configure return an error to begin with. Wouldn't be safer to check if configure didn't fail instead only mysql ? what if we add new lib ?

 

I also change the 'all' target to run all the makefile in subdir so we could check if something didn't broke other like it's currently the case with src/test. (since Sql_Init)

 

make install uninstall bin-clean was also rewritten and taken out as external shell script. I'll talk about them in part 3

 

3) Shell script.

First we using shell script cause bash ain't the default interpreter in all distribution (ksh, tsh,..).

 

athena-start :

Since the .pid file was added to prevent killing other servers with the same name on same host. (like map-server p6900 and map-server p6800 dual server). There a small glitch issue if you attempt to relaunch start while a runnig server is on with the same config, it will fail (socket already in use) but the .pid file will be overwritten with the new process id wich won't correspond to the running server. So now we checking this before attempting start wich I hope will remove question about socket error 5 or etc.

So new func would be :

-status : return whetear the servers are up or down.

-restart : now fully check if server down before attemting restart.

-start : now check if no instance already running (will launch down ones if so)

-watch : auto restart server if taken down (experimental atm)

 

Also I'll save those action into log/map-server.log for exemple.

With these change I think we could remove "char-server.sh, map-server.sh, login-server.sh start" wich the first 3 was only monitoring and the last was a multiple start attemp...

 

install.sh uninstall.sh :
Those 2 new shell are what was somewhat into make install | uninstall | bin-clean.
There being extracted cause we usually have install script outside and also gave the advantage of having more instruction instead depend on make syntaxe.

The previous install process was kinda like take our current repository and move it into install directory. (usually /opt/ or /usr/local/)

While this "ok" it fork the emplacement of src npc was then in 2 different base path (origin path and install path) making change/sync harder and you couldn't reinstall without those folder  into "origin path" (just imagine the nightware for a new script command..)

Also "install path" are usualy under root ownership (security to prevent user to add non wanted apps..) wich wasn't check atm and result in a fail. (root ownership will also harder change a bit).

I therefore prefer to copy file under installation path and make athena-start use it if we have so.

 

-I wont tread /opt/ vs /usr/local/ that more an admin preference, let just say /opt will be easier to see as a whole package.

-db/ was move from etc/ to var/ why ? even if in our case the db is read only it's still meant to be a db and idk maybe one day will writte in it too, db are usually in var/ for that reason not etc/

-Hierarchy of symlink change why ? yes wasn't make sense to have conf/ db/ etc into bin/ directory, but it's common to have binary linked into package dir, wich I did.

Hierarchie of opt/rathena/ is the same as if that /opt/rathena/ was the / one.

-rathena was added in usr/bin/ why ? this allow user to use "rathena start" everywhere as if it was in /opt/rathena, it's now treated as a real user system command.

Why not add /opt/rathena/ into path instead ? didn't really want to bother with .profile and make uninstallation easier. (same go for alias)

 

function.sh

To facilitate script dev I moved common var and function into this file so it could be loaded and use everywhere.

This prevent name mistmach for server declaration, install_path or package name etc..

  • Upvote 4

Share this post


Link to post
Share on other sites

I think it is a great idea to cleanup the leftovers from txt from makefile. Fixing the problems with script files are also a great thing to do. Unfortunately I'm not competent enough with makefiles to revise your changes, but based on your description I like them so far.

 

My only request: just try to test the new settings on as many platforms as possible.

  • Upvote 2

Share this post


Link to post
Share on other sites

was tryed currently on freebsd_9.1 (64); centos 6.3 (32); debian 6.0.3 (64); fedora 18 (64), and ubuntu 12.10 (64).

  • Upvote 1

Share this post


Link to post
Share on other sites
Sign in to follow this