News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

small patch to easy building simutrans on linux

Started by captain crunch, September 19, 2014, 10:46:48 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

captain crunch

As the get_pak.sh and get_lang_files.sh never did the right thing for me, I wrote this patch. Probaly it will make building and running simutrans easier people using *nix OSs.


Ters

There are several things that confuse me here, probably because I'm not using autoconf, or have even upgraded to that revision. But rm -f $(PROGDIR)/get_pak.sh $(PROGDIR)/get_lang_files.sh will certainly be bad (although not "fatal") for those using the old default of building in the root directory. The new default PROGDIR is only set in config.default.in, which may not have been used, or reevaluated.

captain crunch

Quote from: Ters on September 20, 2014, 08:37:58 AM
There are several things that confuse me here, probably because I'm not using autoconf, or have even upgraded to that revision. But rm -f $(PROGDIR)/get_pak.sh $(PROGDIR)/get_lang_files.sh will certainly be bad (although not "fatal") for those using the old default of building in the root directory. The new default PROGDIR is only set in config.default.in, which may not have been used, or reevaluated.

Yes, that is true indeed if you already built simutrans before.
I wrote this patch in the hope to make it easier for people who never built simutrans before, because I found that:
* In the old config.default the simutrans executable got built in the source's root directory, which currently is $(PROGDIR)..
* Then if you start it from there, it cannot find any gui themes, as it searches in $(PROGDIR)
* Then it cannot find any paksets in $(PROGDIR) and if you run get_pak.sh, it goes up one level which would be above the source's root direcory.
* Then it cannot find any fonts.
* Then it cannot find any language.paks. If you run get_lang_files.sh from $(PROGDIR)/simutrans, because by this time one could have figured that this could be the right place, the 'cd simtrans/text' fails, but does not bother and extracs happily all the language directories and *.tab files into the current directory.

HTH!


Ters

Quote from: captain crunch on September 20, 2014, 05:27:31 PM
* In the old config.default the simutrans executable got built in the source's root directory, which currently is $(PROGDIR)..

No it isn't. $(PROGDIR) is by default the build/<configuration> directory. The new config.default.in does however seem to have reverted, which is isn't that unusual (maybe even normal) for a autoconf+automake project.

But you seem to want to run make all and then have a runable installation inside the project workspace, in a version controlled directory thrown together with version controlled files. I don't like that idea, and can't think of any project that does it this way. What I feel Simutrans has always been missing, even more now that it has ./configure, is a make install target. This will copy all the various files from all over the place and generate a complete installation separate from the build direcoty / workspace.

Philip

Projects that require make install rather than letting you run them from the build directory are a major inconvenience, IMHO, particularly for games, which quite reasonably might be installed without root privileges. Having a make install target in addition to the current process is a good idea, though, as long as it doesn't become a requirement.

I'd very much like to be able to build simutrans entirely outside of the tree, rather than in the build/ subdirectory, too. It's easier to work with directories that contain only the version-controlled source files. I don't know how hard it would be to change the build system to do that, though.

Ters

Quote from: Philip on September 21, 2014, 10:02:28 AM
I'd very much like to be able to build simutrans entirely outside of the tree, rather than in the build/ subdirectory, too. It's easier to work with directories that contain only the version-controlled source files. I don't know how hard it would be to change the build system to do that, though.

The typical way for autoconf+automake projects is (if I remember correctly):


./configure --prefix=~/simutrans
make
make install


This would then, if the build system had supported it, have built Simutrans and put in in ~/simutrans. The main difference is that --prefix shouldn't really point to the installation directory, but to the root where to put the typical bin, lib and share directories, which normal Simutrans doesn't use. (I think some distros might have modded Simutrans to do so.) One could perhaps just come up with a better name than --prefix.

Philip

You're right, of course, that --prefix gets around part of the problem, that of requiring root privileges. Still, most projects do support running the program from the build directory without invoking
make install
, and I think that's a good idea. The --prefix argument is often hard-coded into the binary, which would mean you couldn't run the executable I build here because it requires its data files to be in /home/pip/simutrans.

Note that my comment was about being able to build outside of the source directory, which changes the incantation to something like:


mkdir build
cd build
../simutrans/configure
make
./sim


Some projects no longer support the ./configure build-in-the-source-tree approach, because the risk of messing up something when autogenerated files end up in the same directory as source files is too great.

Ters

Quote from: Philip on September 21, 2014, 04:08:05 PM
Still, most projects do support running the program from the build directory without invoking
make install
, and I think that's a good idea.

I have only seen that work for programs that require no data files beyond what is given on the command line. Simutrans is "some assembly required".

Quote from: Philip on September 21, 2014, 04:08:05 PM

mkdir build
cd build
../simutrans/configure
make
./sim


Some projects no longer support the ./configure build-in-the-source-tree approach, because the risk of messing up something when autogenerated files end up in the same directory as source files is too great.

I had forgotten about that way of doing it. At the core is still the an assembly stage, which Simutrans' build script is missing.

prissi

Most libaries I had looked at did not use a build directory. But then, it depends when and where you look ...

I gave up to autoconf a "make install" because such a configure did not run on Unbuntu, as it does not get a valid installpath. Maybe sudo some execution steps would fix it, but that is somewhat even more a hack.

Furthermore downloading all paksets during a make will be not greatly ease developsment, thinking of 200+ MG runnung over the lines. (And if you really want the latest, those paks would need to be downloaded as source and build also from source ;) )

I think I will move this to denied patches, sorry.

Ters

Quote from: prissi on September 21, 2014, 08:35:25 PM
I gave up to autoconf a "make install" because such a configure did not run on Unbuntu, as it does not get a valid installpath. Maybe sudo some execution steps would fix it, but that is somewhat even more a hack.

To actually install simutrans on a system (and not just for one user), one would have to run as superuser from the very start, so no sudo inside the build script.

Quote from: prissi on September 21, 2014, 08:35:25 PM
Furthermore downloading all paksets during a make will be not greatly ease developsment, thinking of 200+ MG runnung over the lines.

Was this ever suggested? If it was in the patch, I certainly did not spot that.

prissi

calling get_pak.sh will do this ...

This line:

+all: $(PROGDIR)/$(PROG) $(PROGDIR)/get_pak.sh $(PROGDIR)/get_lang_files.sh


But my windows make is quite old, so maybe it does not call those for you.

Ters

That doesn't execute get_pak.sh any more than it executes sim.exe.