Reposted from Celestial Heavens:
There is configure file as well as CMakeLists. Right now both of them should work but I’m going to remove autotools before next release - CMake is much more easy to manage.
Run “autoreconf” before “./configure” to regenerate some files. Or use CMake.
(configure script is autogenerated by autotools - we can’t control most of those checks)
I see. CMake does add to the list of requirements, though. But if it will be the only one supported, might as well use that, then.
Also, as a note, I’m writing an installer script for VCMI on Linux, so that it could be installed without hassle by anyone. There’s one more thing that I wonder about, however - when preparing the resources needed, which ones exactly are required? I don’t want to copy anything excessive, and things like DLL files are obviously not needed. Also, what case should the directories use? I know that some installations of HoMM3 have “Mp3” and others have “MP3” etc.
IMHO, I don’t think that we need a installation script for linux, as it’s really simple. Download RPM or DEB file and double-click on it for installation. All what you have to do on your own is to provide original heroes 3 files and copy them to the correct folder which is described in the wiki in detail. As an additional step you can convert Mp3 files to OGG if you’re using fedora.
An one-click installer seems not to be possible unless we don’t have external content dependencies. This would be nice. I think we can help the not so experienced user if we integrate some part of the installation in the mod explorer/browser. (for vcmi 1.0+). The browser checks if original content is available, if not it checks common heroes installation dirs and suggests them to the user. The user may select a suggested dir or select one manually. If the user doesn’t provide any content dir we can print a message a la “please select a heroes content dir or install heroes before”. The mod browser may automatically convert music files on fedora to ogg. The mod explorer/browser should then be the start application where the vcmiclient can be started. (via start game button e.g.) So writing a mod browser in Qt/C++ may be more useful:)
From the other side - less headache for devs. Writing autoconf files is a painful experience.
As for your script - check build_data.sh file. A bit outdated but may work as base.
Directories used by VCMI:
Config - taken as it from source (handled by CMake)
Data - as in H3: SoD
Maps - as in H3: SoD
Mods - taken as it from source, including subdirectories (handled by CMake)
Mods/vcmi - taken from data package: dl.dropbox.com/u/22372764/vcmi/mods/core.zip
Mods/WoG - copied from Era. Same package is here: dl.dropbox.com/u/22372764/vcmi/mods/wog.zip
Mp3 - as in H3: SoD
“handled by CMake” means that installing vcmi via cmake will install these files as well - no need to do this in script.
Not sure about VCMI data package - still thinking about including it into released packages - should make install a bit easier.
Original H3 + WoG setup still works but this one is a bit more clean. Directories are (finally) not case-sensetive, all that Mp3 vs MP3 issues should be gone already.
I’ve been thinking about such functionality for some kind of VCMI Launcher\Mod Manager. Something that we should consider for 1.0 - would be a nice addition for mod system apart from installation checks.
It’s not that simple. First, not all distributions use RPMs or DEBs, and even those are provided for a limited amount of distributions. Second, you can’t select a HoMM3 content directory if you only have a CD. You need to install Wine, which is a huge dependency and I know some people who don’t want Wine to be anywhere near their installations. And when you do install Wine, you need to go through the HoMM3 installation procedure, which takes time, is outdated and misleading. Then you end up with more than what VCMI requires installed, taking up unnecessary disk space. Plus your Wine directory is no longer clean (unless you create a new prefix just for that - which again wastes time and space). And then you need to manually copy things - except that you also need to have root privileges to do that, and even launching a root file manager is difficult in many cases.
So, you get the picture - this is very unfriendly as installation procedures go, to both new users and to veteran users that are either intolerant towards Wine and/or use different distributions than are supported.
What my script does is it automates the procedure. It uses unshield to extract the content from the disc (so no Wine dependencies), and it builds VCMI from source (automatically downloaded from the internet), while also allowing to enter some arguments in the process (which is important for being distribution-independent and for additional optimisation of built code). The whole procedure is verbose, so it’s not difficult to understand, and the defaults are reasonable, so you could just press Enter a few times and it would install VCMI for you, cleanly and from scratch.
There are different versions of HoMM3. The .GOG version consists just of an windows installer executable, don’t know if that files can be accessed easily. There is the LOKI installer for linux. Perhaps there may be a difference between the Shadow of Death and Complete version(regarding installing, don’t know either). Is it really possible to extract .MSI files(whatever) so easily?(no protection?, protection here wouldn’t make sense, ok…) Additionally some users may have heroes 3 installed already on their systems.
Don’t know if the user wants to wait that long(up to 15-20mins). Dev packages of SDL/FFmpeg/Boost have to be installed just for compiling.
Yes, the other versions will have to be tested separately. The ones on CDs are all in InstallShield format, and extracting them is easy. The GOG ones I’m not sure about. The LOKI ones are not supported to begin with, according to your wiki. And if someone already has it installed, good for them, they can use the manual installation procedure
Yea, it depends on a lot of things. But there is no other way to be distribution-independent. And again, there is nothing stopping people from using the RPM/DEB method, if they happen to use those distributions and have Wine installed and be willing to sit through that instead.
Can’t you just statically link everything? I haven’t seen yet a good reason why in Windows it’s a popular and successful method while Linux applications don’t go this way.
I won’t mind such script as long as it will be maintained.
Chance that VCMI will support RoE is really small - this is much harder than optional WoG.
Install from CD should be optional.
For example I don’t have my original H3 CD - after 10 years old disk became garbage. Somebody may copy existing installation from Win or install gog.com version one way or another and use script for the remaining part of the work.
Also optional (in case of no Internet access) - just check for presence of specific files (specified in command line?) and download if missing.
Too distro-specific. Should be done manually or installed from packages.
Universal “make install” is evil - removing\updating may (and will) cause issues.
(Or provide statically linked binaries)
Due to such issues like hardcoded DATA_DIR + autotools this was problematic. In 0.90 this can be avoided (all data can be placed in ~/.vcmi, maybe even DATA_DIR can be relative). Thanks for idea. I really like our recent changes in VCMI
As for why this is not done in general on Linux - package management. On Win you can’t be sure that user will have this library installed and this version is compatible with yours. Usually only apps with complex dependencies or with libraries unavailable in distribution use static linking.
Because until win8 windows=PC(x86 or AMD64 architecture) while linux can run on anything, not just PC or ARM? or perhaps people with some AMD64 processor doesn’t want itlel 386 processor backward compability and prefer optimisation for just their device?
well if any linux with needed libraries can run on TV set which is Neither PC Nor ARM inside - then you will be happy to install VCMI or anything else. If not binary packaging always would make some platform dependence (while it’s nothing bad to have ALSO deb/rpm for PC). Linux people think if something is freedom you shouldn’t artifically limit it, even if it require a bit more work. (BTW: my N900 supports java by icedtea - if I only have reqquired binary libraries for arm I would try playing classic minecraft on the phone - minecraft provides libraries for linux but only PC-linux)
I think his radical ideological linux/foss approach is another one way to go which is also great. I just prefer to not be the only one. Anyway VCMI is foss, yeah? (I know not all people thinks this way but some do and let them have some voices).
Good idea. I should make the CD step (where I get the information on where the CD is mounted) a combo of that and a path to an installed HoMM3. This should be pretty trivial to add.
Yes, I already implemented that. There is a step where the script asks you to enter a path to a source. By default it’s a link to the VCMI sources on the internet, but if you point it at a local tar.gz file, it uses that as a source. And if you enter a path to a directory, it uses that as the root of the extracted source.
I did not implement that just yet, but I am planning to parse the “–prefix” argument and the other related ones given to the configure script in order to figure out where resources should be placed. As for the main VCMI install, doesn’t make have any security that makes sure not to overwrite anything? If so and if the prefix is correct, everything should go fine.
No. Build system (CMake/autotools) may have some checks but “make install” can do virtually anything. Usually such checks are done during packaging into deb/rpm/etc.
But it is unlikely that VCMI install will for example overwrite /bin/sh. Main problem is uninstall/update. To correctly remove or update the game you need
- correctly generated “make uninstall” target. By default CMake does not have that.
- to have exactly same version of the source as used for installation. (unlikely in case of updating)
Othervice old version won’t be removed correctly, overwriting it with newer one may cause issues.
I see. Yes, uninstalling could be a bit of a problem when talking about shared libraries. There is no way to tell whether something is using them or not if it’s outside the package management system, and registering them in the first place is a bit tricky. Though upgrading/uninstalling the /usr/share/vcmi directory should be straight-forward.
A bit off topic, but I’m still curious.
Why do people prefer to provide numerous packages for all major distros (a side question: why distros and not packaging systems?) instead of one universal package that could work on any linux kernel of specified version and target architecture? No matter how many distros you cover, there will be someone who cannot run your software without compiling sources.
The biggest mystery for me is Oracle’s Java package – rpm without specified distro. There are numerous dependencies on JVM in every distribution yet they managed to get out of this mess. I just had to install it and run a few relatively simple commands. I imagine in case of software that nothing depends on (like games) even those commands wouldn’t be needed. Replace package with .sh script that checks necessary things (like architecture) and copies files and you are (almost) 100% distro independent. Life’s simple. Packaging’s simple. Everyone’s happy.
Package management does not solve architecture issue either (packages are precompiled for a limited set of architectures), yet it’s popular. Statically linked program with .sh script could detect architecture and you could even have architecture-independent installers!
That’s a mystery for me, too. The problem of providing distro independent packages is code compiled into machine code like C++ software. It may be possible to provide such general packages, but it’s complicated. I don’t think that this would be a easy and a fast solution. Google provides for their chrome browser a generic .deb package for Debian/Ubuntu and a generic .rpm package for Fedora/openSUSE officially. There are community built packages for several distros like Mageia, CentOS, …
It’s ok that we provide “official” VCMI packages for the most popular distros. The rest is not our part(there are hundreds of distros). Battle of Wesnoth devs distance themselves from building any packages for linux distros. They say it’s part of some volunteers which provide distro-specific builds. I want to integrate VCMI beginning from the first major release in the official Fedora repos(they’re some guidelines, some recording conditions,…). So a command like “sudo yum install vcmi” would be enough to install VCMI(problem is that VCMI has dependency to ffmpeg which belongs to rpm fusion, which is another topic…).
This is the most complex part - we have new or outdated configs with each release. Same goes to data package.
Different distros have different version of libraries. We should either provide several binaries (as it now) or use static linking. Such libraries as boost or ffmpeg have habit of changing API too often.
Besides - creating all that packages is one-click action for me.
Setting up some rpm-base system on deb-based without virtualization is complicated (or impossible). And virtual systems are really slow…
Static build packaged as rpm? Nice - works on any rpm-based distro, correct uninstall.
- Large package. For me installing Java requires twice smaller download size.
- Multiple copies of same package in system. Not a huge issue for desktop but problem for security-critical systems - any bugs fixed in included libraries won’t be fixed in library from this package.
BfW is already included (and maintained) in most of Linux distros and have quite big community. In case of VCMI we have to be those “volunteers”
BTW - some time ago I found VCMI package in one of user-provided repository for Arch (IIRC). First step is done
I’m not thinking of leaving the old installation. I don’t see how removing the vcmi directory and rebuilding it when a new version arrives could be problematic.