Autotools vs SCons configure/build system

[thelusiv]

I started reading through the docs for autotools and found them rather nasty. It was really tough to figure out where to start with it, so I started asking around for help. Many of my friends recommended dumping autotools in favor of a more straightforward configure/build system, downloads page...Now, once you have SCons and Python, and have checked out the SCons tree, build VDrift thus:<pre>cd vdrift-sconsscons </pre>To see optional components type<pre>scons -h </pre>This will list the only option I've configured so far, fmod. To compile with fmod:<pre>scons fmod=1 </pre>The default is to compile with openal. Sadly, I haven't worked all the bugs out yet, and compiling with openal fails for me. This will be fixed soon (in fact, I'm hoping Joe will take a look at it for me and tell me what I've botched :wink.So far, I really like SCons. It has a lot of things going for it - it seems faster, it doesn't involve cryptic M4 macros or shell scripts, no need even for a separate configure script and Makefile, it wraps it all up into one file ("SConstruct", and in the subdirectories "SConscript") - which drastically reduces clutter in the root directory of the VDrift tree. It has as much flexibility as the Python programming language. In only a few hours I set up what we already have (a configure + build system with an optional library). I even improved on it slightly - now everything under src/vamos/ is compiled as a library that is linked with vdrift when it gets compiled. Best of all it seems easy to work with. I don't think it will be very hard to adapt the build system for other libraries or options in the future, namely setting up install targets.So, if all of you who usually follow the latest in the SVN tree could check this out and try it, and please let me know what you think. This may become VDrift's permanent configure/build system if it works OK for everyone.

[thelusiv]

Oh yeah, one thing I forgot - to clean the build (same as "make clean") one simply types<pre>scons -c</pre>It is really worth it to read their man page.You may notice when the program is built everything goes into a new directory called build/ - it even copies the source files and SConstruct/SConscript files there. This is because I told it to, and the advantage here is that the .o files don't get all mixed in with the source files in the src/ directory, so it doesn't ruin tab-completion for those who like to edit sources on the command line between compiles. The vdrift binary also ends up in build/ so the runtime/setup script won't work anymore (doesn't matter though, it's about to get replaced with an install target anyway).

[joevenzon]

Is there anything we need done that scons can do that autotools can't? Is it worth the extra dependencies?

[FFuser]

Is there anything we need done that scons can do that autotools can't? Is it worth the extra dependencies?

It is not an extra dependency, it replaces another dependency.As thelusiv said it is faster and I think it is more usable to develop

[thelusiv]

It's not really an additional dependency, it replaces the dependecy on m4 and shell scripts with a dependency on Python. Nearly every Linux system has Python (I can't think of any who don't). SCons itself can be distributed with the program if we choose to, check their download page, they have a "scons-local" package that is intended just for this. That way users do not necessarily have to have SCons installed to compile.edit: Ulitmately, though, the best way to figure out if it's good or not just try it out. About dependencies - remember, right now we are requiring that users have make and auotmake installed (and the right version! ugh), and if they want to regenerate the build they have to have autoconf and other stuff too.

[thelusiv]

I just checked in changes that fix building with OpenAL and FMOD. Before I wasn't defining HAVE_OPENAL during OpenAL compiles, that is fixed now. During FMOD compiles I defined HAVE_FMOD even though it's not used, just so one can see what's going on.Next, I need to make SCons prepare a header file that contains paths to various things, and also figure out a way to let the user change these paths.

[joevenzon]

Okay, sounds like people are for scons.For the paths, just make it define DATA_DIR to the path location... that is, instead of defining HAVE_OPENAL, make it define DATA_DIR with the path. Support for it isn't in SVN yet, but it won't be hard for me to add.

[thelusiv]

OK, I will do that. If you add support for that, add it to the scons-test branch, if you could. I think the branch is right now in working order and compilable (I have since broken my local copy to add new features)...

[joevenzon]

Um...I'm going to wait on that, instead of working on the same files in different branches. I dunno if all of this branching was really worth it... oh well. :-)

[thelusiv]

Alright tonight I checked in changes that fix a bunch of things, now there is an install target whose prefix directory can be changed, and is provided to VDrift at compile time as the #define DATA_DIR (defaults to "/usr/share/games/vdrift"). I set it up so that each of the subdirectories of DATA_DIR are exactly like those in runtime/data/.The only big thing I need to add now is a define for the user settings directory (already available as an option but doesn't currently do anything). It defaults to ".vdrift" - note that I am not making it a full path to /home/user/.vdrift - I think that VDrift should get the HOME environment variable from bash or do some Windows trickery to get that in win32 land. This way each user on the system will have a separate settings directory. The contents of this directory will be as discussed before, basically the contents of runtime/ besides runtime/data/ and those .dll files that I haven't figured out the purpose of yet.

I dunno if all of this branching was really worth it... oh well. :-)

Come on, branching is fun!! hock:

[joevenzon]

yeah, i guess if your scons branch has been breaking things then that would be annoyingmy netplay branch totally isn't breaking anything ,thoughanyway, sounds like you've got scons all figured out. does it check for the proper libs?note to self: move lists/menus, lists/control_list, lists/fontspacing*, and maybe lists/keys and lists/videomodes to some path inside data

[thelusiv]

my netplay branch totally isn't breaking anything ,though

whose fault is that?!?!? :wink:

anyway, sounds like you've got scons all figured out. does it check for the proper libs?

Yeah I think I've got the SCons stuff sorted out. It was satisfyingly painless. Yes it checks for all the necessary libs, as configure did.

note to self: move lists/menus, lists/control_list, lists/fontspacing*, and maybe lists/keys and lists/videomodes to some path inside data

I did it for you in the scons-test branch. the files cammode, videoconfig, and controls were moved to runtime/data/settings/ and the rest of the directory was moved to runtime/data/lists/. The contents of the settings directory should be the default settings and these files can be copied to the {user's homedir}/SETTINGS_DIR directory when the game is run for the first time by a user.By the way today I added the SETTINGS_DIR setting to the flags today, so that and DATA_DIR can be handled by the game now. I also added section comments so it's really obvious what's going on in the SCons files now. Also I added /usr/X11R6/lib to the LIBPATH so hopefully we won't have this problem anymore.Next I'm going to work on getting SCons to build a source distribution for us. Other than that, there's not much else I can think of that needs to be done to the SCons files right now. Now mostly those data and settings directory defines need to be handled by the game, because now it compiles well but doesn't run right because I've moved things around...so, do you want to do this Joe? If so, do you want to work on the scons-test branch or do you want me to merge back into the trunk? Or, do you want me to do it? The only reason I would be wary to merge back into the trunk right now, is if for some reason we decide to go back to autotools, I'd rather not junk that whole system in SVN just yet.

[joevenzon]

i won't get to it until i get basic netplay going, which could be sunday or it could be several weeks awayyou could do it if you want, but keep in mind that we'd have to merge the changes together later, since we'll be touching a lot of the same filesalso, i'd like to eventually make a clean, abstracted interface for game config stuff (like a gameconfig class or something)

[thelusiv]

I might do it if I get around to it, after I finish setting up a way to build a source package.A gameconfig class would be nice, and this would let us combine all the little config files into one.

[thelusiv]

OK, I have gotten SCons set up to do a lot of cool things, like build source and binary packages automatically. I've also restructured things a little bit, the runtime/ directory is gone now. data/ is moved to the root directory and everything like lists, settings etc. went into data. I also moved some things out of the root, like the project files and the win/ directory - now these reside in tools/anjuta/ and tools/win/ respectively. The .dll files from runtime went into tools/win/dll/.Now I've been trying to code the DATA_DIR variable into the game. It's not possible just to replace every string that needs it with DATA_DIR + ... because in a lot of places this is an attempt to concatenate two string literals, which the compiler doesn't like. So, I thought it would be better to just define a static global variable that would hold it. So now, in main.cpp, there is a line<pre>extern const string data_directory = DATA_DIR;</pre>and in all the files that use data_directory, I've got<pre>extern const string data_directory;</pre>This seems to be working OK now. Is there a better way to do this? I think the only way to make it better would be to have a global configuration class or something, that way this variable could be loaded from a file instead of hard-coded in.Next, I need to set up some way of handling the settings directory. Now, the game will run if executed after an install, it finds some splash graphics, but as soon as it tries to load other stuff (like, anything in lists/) it fails because I've moved that stuff out from under it...Stuff to do:* find the user's homedir (this code will not be portable, I think we'll have to probably start defining something that tells it whether we're compiling on Win32 or Linux if not already)* check to see if there's already a SETTINGS_DIR (defaults to ".vdrift")there* if not, create it and copy defaults from DATA_DIR/settings/* if so, read settings from it* logs should be saved to SETTINGS_DIR/logs* replays should be saved to SETTINGS_DIR/replays* screenshots should be saved to SETTINGS_DIR/shots or something like that