How to compile MegaGlest 3.4.0?

[Gallaecio]

I was compiling 3.3.7.2 with this:

Code: [Select]

  ./configure --prefix=/usr
 
  # wxgtk is not used in this package.
  WX_AVAILABLE=no \
  jam
But it didn't worked with latest release, 3.4.0. There's no 'configure' script. Then, I got to the wiki and tested CMake way:

Code: [Select]

  mkdir build && cd build
  cmake \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_BUILD_TYPE=RelWithDebInfo \
    ..
  make
But that didn't work either. "The source directory does not appear to contain CMakeLists.txt". Did I miss something, has anything about compilation changed from 3.2?

PS: nice new website.

[titi]

We changed to cmake with this release and obviously there is something missing now. We try to fix it the next days ( if easily possible )

Meanwhile checkout svn to build as described here:
https://docs.megaglest.org/MegaGlest#Source_Code_.2F_Compiling

Hint: use SVN Revision 1688

[softcoder]

Fixed.. all of the latest files are now on Sourceforge (including updated Linux installers which are about 60MB smaller).

Get the source release package from here. https://sourceforge.net/projects/megaglest/files/current_release/

To build run (from the folder ABOVE the source subfolder):

mkdir build
cd build
cmake -DWANT_SVN_STAMP=OFF ../
make -j 2 (where 2 is # or CPU cores for faster builds)

voila

[tomreyn]

I've rearranged the development related content on the wiki a little today. There is now a page dedicated to development at https://docs.megaglest.org/MG/Development

A more easily remembered location pointing to the same information is http://megaglest.org/development.html (or just go to http://megaglest.org and click on development).

[LuckAs]

Fixed.. all of the latest files are now on Sourceforge (including updated Linux installers which are about 60MB smaller).

Get the source release package from here. https://sourceforge.net/projects/megaglest/files/current_release/

To build run (from the folder ABOVE the source subfolder):

mkdir build
cd build
cmake -DWANT_SVN_STAMP=OFF ../
make -j 2 (where 2 is # or CPU cores for faster builds)

voila

Thats is greate, but where is reason for command ?!
# make install
The section of Makefile for install not found
The compiled binaries dont strip before installation (from source and from binary intaller).
The megaglest-data sources should have the one-root folder before archiving. It's LSB way.

[titi]

- MG is not ready to install in linux systems yet. This will maybe be changed, but at the moment its meant to be installed in your home directory not in the system, because everyone quickly starts to mod or install mods in MG and as you know files like glestuser.ini are placed in the installation base
-  Data package not LSB conform.... LSB=LinuxStandardBase? MG is not linux only
-  We wanted the binary in a non stripped form as default! If you want it stripped use the release konfiguration.

In general we have the problem that MG is cross platform! Not linux or windows or bsd or mac or whatever  only.
But you are welcome to produce such a LSB conform source package   .

Our current way to make it available are installers, but we will try to make it at least more linux friendly by using a .megaglest directory, as we all use linux.

[LuckAs]

- MG is not ready to install in linux systems yet. This will maybe be changed, but at the moment its meant to be installed in your home directory not in the system, because everyone quickly starts to mod or install mods in MG and as you know files like glestuser.ini are placed in the installation base
-  Data package not LSB conform.... LSB=LinuxStandardBase? MG is not linux only
-  We wanted the binary in a non stripped form as default! If you want it stripped use the release konfiguration.

In general we have the problem that MG is cross platform! Not linux or windows or bsd or mac or whatever  only.
But you are welcome to produce such a LSB conform source package    .

Our current way to make it available are installers, but we will try to make it at least more linux friendly by using a .megaglest directory, as we all use linux.

I think has metod for all platforms:
1. Install in linux must be have,
2. The LSB (yes = LinuxStandardBase), say:
- binaries files =>/usr/bin/ (or /$PREFIX/bin)
- libraries => /usr/%_lib/  (or /$PREFIX/lib)
- data files =>/usr/share/$NAME_OF_APPS/ (or /$PREFIX/share/$NAME_OF_APPS/)
- user files => $HOME/.$NAME_OF_APPS/
Thats possible from global variables in "configure and make" scripts, and the $PREFIX of installation as the global variable may be as $HOME/$PATCH_TO_INSTALL/ for linux and other directory for different platform (Mac, Win) - it's better compability of today situation in code.
Moreover, in the SVN code already prefixes to locate the directory for game data.
The mods directories should be in $HOME/.$NAME_OF_APPS/mydata/=> maps/  scenarios/  techs/  tilesets/  tutorials/
the copies off original ini-files (megaglest.ini, megaglestuser.ini, lastCustomGamSettings.mgg, servers.ini, glestuserkeys.ini, glest.log, configuration.xml, etc.) must be in => $HOME/.megaglest/ (and for Windows platforms => C:\Users\$USERNAME\..\ - for Win7)
And, the rules for run the apps and load dates:
- find first configurations files in $HOME/.$NAME_OF_APPS/
- if have not files - find configurations files in /usr/share/$NAME_OF_APPS/ (first run apps)
- if this files found, copy this files to $HOME/.$NAME_OF_APPS/ and run apps with configurations in $HOME/.$NAME_OF_APPS/
- the dates find first in $HOME/.$NAME_OF_APPS/mydata/: maps/  scenarios/  techs/  tilesets/  tutorials/ (or other)
- if "dates" not found in $HOME/.$NAME_OF_APPS/mydata/ find in /usr/share/$NAME_OF_APPS/ (or in other folder, as $GAME_DATA_PATCH with compillation apps)
3. Icons, destop-file, etc. its no problem
Thanks for help

[tomreyn]

There has been no claim made that MegaGlest is LSB compliant. Same about Debian. While this can be long-term goal, it is surely not something worth reporting bugs about at this time. No need to argue there.

[will]

I think it would be really cool if someone who knows the intricacies of LSB could make Glest LSB-compatible - which is a suitable layout across all the nix.

And also drive - is it as simple as submitting? - MG (and GAE?) into the default depos available to Ubunutu and Fedora

Clearly this would be a burden to the MG team, which is already stretched.  Are there any daring volunteers please?

[LuckAs]

I think it would be really cool if someone who knows the intricacies of LSB could make Glest LSB-compatible - which is a suitable layout across all the nix.
And also drive - is it as simple as submitting? - MG (and GAE?) into the default depos available to Ubunutu and Fedora
Clearly this would be a burden to the MG team, which is already stretched.  Are there any daring volunteers please?

The LSB-compatibilities is not need more working in this project (code compile with CMAKE witch have standard function for make prefixes).
But temporary I make the binary and source package for RPM-based distros at this week (my is Mandriva i586, x86_64).

[Andrew Clark]

The LSB-compatibilities is not need more working in this project (code compile with CMAKE witch have standard function for make prefixes).
But temporary I make the binary and source package for RPM-based distros at this week (my is Mandriva i586, x86_64).

i'm roll rpm package for altlinux distro, but i'm got error - data files are loaded from my home directory, but not from /usr/share/games/megaglest/.
in previous releases ini files are loaded from users home direcrtory, but this is does not work anymore.

[softcoder]

As far as i know this behaviour did not change. However it is possible to specify custom paths via commandline (see --help for details) example:

Code: [Select]

--data-path=x Sets the game data path to x
                      example: ./glest.bin --data-path=/usr/local/game_data/
--ini-path=x Sets the game ini path to x
                      example: ./glest.bin --ini-path=~/game_config/
--log-path=x Sets the game logs path to x
                      example: ./glest.bin --log-path=~/game_logs/

Also of note is the 'user data content' folder is specified in glest.ini as:

UserData_Root=mydata

All options in glest.ini and glestkeys.ini can be overridden 'per user' in glestuser.ini and glestuserkeys.ini

Thanks

[Andrew Clark]

As far as i know this behaviour did not change. However it is possible to specify custom paths via commandline (see --help for details) example:

Code: [Select]

--data-path=x Sets the game data path to x
                      example: ./glest.bin --data-path=/usr/local/game_data/
--ini-path=x Sets the game ini path to x
                      example: ./glest.bin --ini-path=~/game_config/
--log-path=x Sets the game logs path to x
                      example: ./glest.bin --log-path=~/game_logs/
Also of note is the 'user data content' folder is specified in glest.ini as:
UserData_Root=mydata
All options in glest.ini and glestkeys.ini can be overridden 'per user' in glestuser.ini and glestuserkeys.ini
Thanks

Thank you for the tip, i'm changed startup script, so game is started normally.

[RedDwarf]

I have never played Glest/Megaglest. But since someone asked for the an openSUSE package for the 3.4.0 version I looked into it and didn't like the script that was used previously (with symlinks from the home folder to the real data dirs). So I have created a quick patch to do the things correctly(TM):

http://sourceforge.net/tracker/?func=detail&aid=3181371&group_id=300350&atid=1266778

Since I never played the game it's not very tested. But, as I comment in the Sourceforge page, this isn't something Linux specific, in Windows the same should be done. In Linux we just have a longer history doing this, but Windows is catching up.

[LuckAs]

Hi!

I allready compiled the packages (RPM/SRPMS) for Mandriva:
http://igroup.biz.ua/doku.php?id=repository

Code: [Select]

Need for install on Mandriva 2010 i586 (32bit):

Curl update:
http://igroup.biz.ua/mandrakelinux/contrib/curl-7.21.3-1mdv2010.0.i586.rpm
http://igroup.biz.ua/mandrakelinux/contrib/libcurl4-7.21.3-1mdv2010.0.i586.rpm
http://igroup.biz.ua/mandrakelinux/contrib/libcurl-devel-7.21.3-1mdv2010.0.i586.rpm

Game Date:
http://igroup.biz.ua/mandrakelinux/contrib/megaglest-data-3.4.0-1mdv2010.0.noarch.rpm

Game Binaries:
http://igroup.biz.ua/mandrakelinux/contrib/megaglest-3.4.0-1mdv2010.0.i586.rpm

Need for install on Mandriva 2010 x86_64 (64bit):

Curl update:
http://igroup.biz.ua/mandrakelinux/contrib/curl-7.21.3-1mdv2010.0.x86_64.rpm
http://igroup.biz.ua/mandrakelinux/contrib/lib64curl-devel-7.21.3-1mdv2010.0.x86_64.rpm
http://igroup.biz.ua/mandrakelinux/contrib/lib64curl4-7.21.3-1mdv2010.0.x86_64.rpm

Game Date:
http://igroup.biz.ua/mandrakelinux/contrib/megaglest-data-3.4.0-1mdv2010.0.noarch.rpm

Game Binaries:
http://igroup.biz.ua/mandrakelinux/contrib/megaglest-3.4.0-1mdv2010.0.x86_64.rpm

Data files from "megaglest-fixed_data-3.4.0.7z"
The all user-files stored in ~/.megaglest/*, add russian and ukrainian base translations with support cyrillic in ini-file, create a run-files megaglest*
Welcome!

[tomreyn]

RedDwarf and LuckAs, in case you plan to continue providing RPMs in the future, please consider subscribing to the announcement mailing list.
You may also need to update the megaglest-data package you built as per http://glest.org/glest_board/?topic=6548.0

[LuckAs]

RedDwarf and LuckAs, in case you plan to continue providing RPMs in the future, please consider subscribing to the announcement mailing list.
You may also need to update the megaglest-data package you built as per http://glest.org/glest_board/?topic=6548.0

Yes, I can to continue provide RPMs in the future, and will subscribe to announcement.
It is desirable that I was able to upload files to the server SF.net or somewhere else, because I do not have enough space on own server
My build based on megaglest-fixed_data-3.4.0.7z.

[tomreyn]

Do OpenSUSE packages also work on Mandriva? If so, I guess it's enough to just have the ones RedDwarf intents to provide...
I talked to someone the other day regarding OpenSUSE RPM's, too, who was trying to get them to build on the OpenSUSE buildd. I assume this was you, RedDwarf?

[LuckAs]

Do OpenSUSE packages also work on Mandriva? If so, I guess it's enough to just have the ones RedDwarf intents to provide...
I talked to someone the other day regarding OpenSUSE RPM's, too, who was trying to get them to build on the OpenSUSE buildd. I assume this was you, RedDwarf?

I think it's possible, take my SPEC-files, make some changes (add the patches, etc) and build in OpenSUSE:
http://igroup.biz.ua/mandrakelinux/contrib/megaglest-data.spec
http://igroup.biz.ua/mandrakelinux/contrib/megaglest.spec

[RedDwarf]

I don't really have plans of becoming the openSUSE RPM maintainer. User joop.boonen was the one doing it in openSUSE, but since he has not done it for 3.4.0 and someone asked I did it this time.
openSUSE maintain (builds and hosts) it in its own "games" repository (https://build.opensuse.org/package/files?package=glest&project=games / http://download.opensuse.org/repositories/games/), there are no plans of submitting RPMs to upstream (you ;-) ). We build different versions for each openSUSE version... so no, cross-distro compatibility isn't a priority in those packages (I explained how to achieve that in https://forum.megaglest.org/index.php?topic=4991.msg67342#msg67342).

Spec files can be shared with Mandriva, sure. And the openSUSE Build Service can create RPMs for Mandriva... but we are still waiting for someone from Mandriva helping us to create the repository metadata (that is Mandriva specific): http://lists.opensuse.org/opensuse-buildservice/2010-10/msg00143.html

[LuckAs]

May simply, will try - $ rpm --rebuild megaglest-3.4.0-1mdv2010.0.src.rpm
I think some problems may be have:
- section of "BuildRequires" must be changed to SuSe name of packages
- need update the curl >=7.21
...