Re: packaging vcmi
Hi,
Quoting Markus Koschany (2014-03-17 19:45:04)
> You can try to pass CFLAGS, CXXFLAGS and LDFLAGS to CMake by overriding
> dh_auto_configure with e.g.
>
> CFLAGS:=$(shell dpkg-buildflags --get CFLAGS)
> CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS)
> #CFLAGS+=$(CXXFLAGS)
>
> dh_auto_configure -- \
> -DCMAKE_C_FLAGS="$(CFLAGS)" \
> -DCMAKE_CXX_FLAGS="$(CXXLAGS)"
>
> You can also pass CXXFLAGS to CFLAGS or vice versa. It depends mostly on
> upstream's (broken) build system. Sometimes they forget to add variables
> for custom CFLAGS or CXXFLAGS to CMakelist.txt. Your other option is
> then to patch CMakelist.txt and forward the changes upstream.
after having tried that and other things without avail I tried using
export DEB_BUILD_HARDENING=1
in debian/rules. This enables hardening-wrapper and should thus work no matter
what goes wrong in the build system. Interestingly the problems remain. I tried
running hardening-check manually on the generated binary:
$ hardening-check ./obj-x86_64-linux-gnu/server/vcmiserver
./obj-x86_64-linux-gnu/server/vcmiserver:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: no, only unprotected functions found!
Read-only relocations: yes
Immediate binding: yes
The output is not only unexpected because hardening-wrapper was used but also
because investigating the build log reveals that there was no call to c++
without the -D_FORTIFY_SOURCE=2 flag passed for example. Still, no functions
are fortified. Weird. Possibly I should ask on the debian mentors list about
this or do you have another idea?
> It's a simple packaging issue. VCMI is the free engine and Heroes of Might
> and Magic 3 is the (non-free) game. The game should depend on the engine not
> vice versa.
This is an interesting way to look at things. I thought since the engine is of
not much use without assets, should the engine not depend on something to
become useful? If it doesnt need to depend on the assets, then there is no
reason for it to be in contrib instead of main.
> That leaves you with the following options:
>
> If Heroes of Might and Magic is non-free but distributable, you can
> prepare a package for non-free which in turn depends on vcmi.
>
> If the game is non-free and non-distributable game-data-packager is your
> tool of choice.
Heroes of might and magic 3 is non-free and non-distributable. One good thing
is, that it can be obtain without DRM on gog.com without much hassle.
I had a look at game-data-packager earlier today. Surely I can write up a patch
for it to support building a heroes of might and magic 3 package which vcmi can
then use. So far, upstream provides a bash script called vcmibuilder to do the
downloading and extracting of resources.
> You can avoid any criticism when you create a distinct vcmi-data package that
> provides enough data for demonstrating the basic gameplay and perhaps some
> documentation how people can built upon this work. Then vcmi-data (main)
> depends on vcmi (main) and Heroes3 (non-free) also depends on vcmi (main).
Okay so this is how it would look like when the assets depend on the engine.
Interesting.
Then what I might want to do would be to create a very tiny mod for vcmi which
includes only one town, one hero, one unit and only a handful of map objects.
The graphics for all of this can be poorly drawn as it's only meant for
demonstration purposes.
> If the package description is meaningful enough, those who want to play
> Heroes3 have to install the non-free data package and everyone else can start
> developing a free replacement.
Sounds like a plan!
> It would be great if upstream developed some free tools so that others could
> create more free content for their engine.
Indeed. But they are also very open to patches and improvements, so if somebody
else creates something that integrates well, I'm sure it will be added.
Thanks for your help!
cheers, josch
Reply to: