Goodbye Autotools, hello CMake and minizip #147
Conversation
|
Travis CI runs Ubuntu 14.04 which does not have a minizip package. |
|
@zturtleman If only. Ubuntu Trusty (14.04) does have /usr/include/minizip/unzip.h in libkml-dev package. Ubuntu Precise (12.04), however, does not. Travis runs Precise. |
|
Oh, I forgot it wasn't the newest Ubuntu LTS. |
| missing | ||
| po/stamp-it | ||
| src/gamesxml2c | ||
| .*.swp |
There was a problem hiding this comment.
.*.swp files are not build files, they are temporary files created by vim, the editor. gitignoring them prevents users to commit temporary files while they edit some files.
There was a problem hiding this comment.
https://news.ycombinator.com/item?id=1688068
There is no place in tree for such garbage to start with. Gitignoring it makes your sources look like a hoarder's trash can.
|
Woaw, it’s a very good job ! 👍 I like a lot that:
😍 @jmallach, @lnussel, I know these patches will change the way you build packages but I hope this job will facilitate a lot everyone’s build procedures in long term. @Slashbunny, when this PR will be merged, you will need to update your So, @jmallach, @lnussel, and @Slashbunny, if you have some suggestions to help distro packaging, feel free to write down them. This work is made to help everyone, including you ! 😏 |
| @@ -5,12 +5,12 @@ compiler: | |||
| - gcc | |||
|
|
|||
| before_install: | |||
| - wget -q -O- https://launchpad.net/ubuntu/+archive/primary/+files/libminizip-dev_1.1-5_amd64.deb | sudo dpkg -i - | |||
There was a problem hiding this comment.
see https://travis-ci.org/XQF/xqf/jobs/67411920
Try something like that:
wget -q -O/tmp/libminizip-dev_1.1-5_amd64.deb https://launchpad.net/ubuntu/+archive/primary/+files/libminizip-dev_1.1-5_amd64.deb
sudo dpkg -i /tmp/libminizip-dev_1.1-5_amd64.deb
But a more elegant way could be to do apt repository pinning, if travis-ci allows it.
|
about https://travis-ci.org/XQF/xqf/jobs/67418533 it seems the pinning way is the only way |
|
@skybon: try something like that (not tested): If there is no mistake in this code, it means “if distro is older than 15.04, add the vivid repository, blacklist the whole vivid repository, then explicitly install cmake and its dependencies (and only its dependencies) from the vivid repository”. |
|
Hey, well, Why I’m testing/installing cmake to install minizip ? I had an hard day today, my mind is blowing. This is better: If there is no mistake in this code, it means “if distro is older than 15.04, add the vivid repository, blacklist the whole vivid repository, then explicitly install libminizip-dev and its dependencies (and only its dependencies) from the vivid repository”. |
|
This attempt does not use |
|
I am totally unconvinced we need to switch build systems. I see no real feature in what Artem outlines, but I see it makes us diverge from what the gtk world does. Not really convinced. :( On 18 juny de 2015 17:41:02 CEST, Artem Vorotnikov [email protected] wrote:
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
@jmallach Can you explain the contents of every one of 30 Autotools files, part by part? I certainly can for the CMake listfile. The transparency and maintainability is the first and foremost feature of any build system. What if we happen to develop a feature that requires a new dependency? How are you going to modify build system? It'll take us exactly 5 minutes to enable it in CMake. Not so fast with Autohell. Moreover, current build toolchain leaves your source tree garbled with intermediary and binary files, forcing you to use clean.sh if pristine sources are of value to you. And what is 'GTK world', GNOME? GNOME is a GNU project and (afaik) is by policy required to use Autohell. GNU is a bit stuck in 80s where GTK is a toolkit, CMake detects it and works without any hassle with 5 lines of code. That's the only thing that matters. |
|
@jmallach said:
Valid argument ✅ @skybon said:
Valid argument ✅ @skybon said:
Valid argument ✅ @skybon said:
Invalid argument ❌ @jmallach said:
Invalid argument ❌ I personally have no preference for a build system or another, but personally I have a strong preference for solutions that are simpler than others. Whatever the solution is, if it's simpler, it's better. The current build system is very problematic :
For your information, this is how I build sourcedir="${HOME}/dev/xqf"
builddir="${HOME}/build/xqf"
mkdir -p "${builddir}"
rsync -a -v --delete-after "${sourcedir}/." "${builddir}/."
cd "${builddir}"
./autogen.sh
./configure --with-qstat="/usr/bin/quakestat" --prefix="/usr"
cd "${builddir}/src"
make gamelist
cp -a "${builddir}/src/games.c" "${sourcedir}/src/games.c"
cd "${builddir}"
make
fakeroot checkinstall --default --fstrans=yes --install=no --pkgname=xqf --pkgversion="1.0.6.2~git" make installThis is how I build sourcedir="${HOME}/dev/xqf"
builddir="${HOME}/build/xqf"
mkdir -p "${builddir}"
cd "${builddir}"
cmake -DWITH_QSTAT="/usr/bin/quakestat" -DCMAKE_INSTALL_PREFIX="/usr" "${sourcedir}"
make
fakeroot checkinstall --default --fstrans=yes --install=no --pkgname=xqf --pkgversion="1.0.6.2~git" make installI have no preference for a particular build system, but I have a preference for which simplifies the maintenance work, and in this regard, whatever the solution he uses, skybon is doing the job and it seems his is doing it well. That said @jmallach, I do not want to offend you. I have great esteem for your work and all that time you spent to maintain xqf all these years. I am obliged to gratitude towards you, and @skybon is obliged to gratitude towards you for this reason. We could not do this job today if you had not maintained When @skybon started to tell me about his initiative to convert the build system to cmake, I told him he should convince you first, and I told him that he must make your job easier. So, I think the current work @skybon is doing is very valuable and very good, but if you need something more, please ask it to him. This current effort is not done to annoy you but to help you. If there is some problems to fix in this implementation, please ask @skybon to fix them, but please, let's use this beautiful work. |
|
@skybon, do not give up too quickly. 😛 Use that in the before_install:
- sudo apt-get update -qq
- sudo apt-get install -q -y qstat intltool
- echo 'install libminizip-dev from ubuntu vivid if current release is older than vivid:'
- echo 'c2V0IC14CgojIGlmIHJlbGVhc2Ugb2xkZXIgdGhhbiB2aXZpZCAoMTUuMDQpCmlmIFsgIiQobHNiX3JlbGVhc2UgLXNyIHwgY3V0IC1jMS0yKSIgLWx0ICcxNScgXQp0aGVuCgoJIyBhZGQgdml2aWQgcmVwb3NpdG9yeSAobGlibWluaXppcC1kZXYgaXMgc2hpcGVkIGluIHVuaXZlcnNlKQoJY2F0ID4gJy9ldGMvYXB0L3NvdXJjZXMubGlzdC5kL3VidW50dS12aXZpZC1tYWluLmxpc3QnIDw8LUVPRgoJZGViIGh0dHA6Ly9hcmNoaXZlLnVidW50dS5jb20vdWJ1bnR1IHZpdmlkIHVuaXZlcnNlCglFT0YKCgkjIHBpbiB2aXZpZCByZXBvc2l0b3J5IHRvIGRpc2FibGUgcGFja2FnZSBpbnN0YWxsYXRpb24gZnJvbSB0aGlzIHJlcG9zaXRvcnkgYnkgZGVmYXVsdAoJY2F0ID4gJy9ldGMvYXB0L3ByZWZlcmVuY2VzLmQvdml2aWQtcGlubmluZycgPDwtRU9GCglQYWNrYWdlOiAqCglQaW46IHJlbGVhc2Ugbj12aXZpZAoJUGluLVByaW9yaXR5OiAtMTAwCglFT0YKCgkjIGFkZCB0aGUgdml2aWQgcmVwb3NpdG9yeSBrZXkKCWFwdC1rZXkgYWR2IC0tcmVjdi1rZXlzIC0ta2V5c2VydmVyIGtleXNlcnZlci51YnVudHUuY29tIDNCNEZFNkFDQzBCMjFGMzIKCgkjIHVwZGF0ZSB0aGUgcmVwb3NpdG9yaWVzCglhcHQtZ2V0IHVwZGF0ZSAtcXEKCgkjIGluc3RhbGwgbGlibWluaXppcC1kZXYgKGFuZCBkZXBlbmRlbmNpZXMpIGZyb20gdml2aWQKCWFwdC1nZXQgaW5zdGFsbCAteSAtcSAtdCB2aXZpZCBsaWJtaW5pemlwLWRldgpmaQo=' | base64 -d | sudo -s
- ./autogen.shThe cryptic line is an encoded script that does: set -x
# if release older than vivid (15.04)
if [ "$(lsb_release -sr | cut -c1-2)" -lt '15' ]
then
# add vivid repository (libminizip-dev is shiped in universe)
cat > '/etc/apt/sources.list.d/ubuntu-vivid-main.list' <<-EOF
deb http://archive.ubuntu.com/ubuntu vivid universe
EOF
# pin vivid repository to disable package installation from this repository by default
cat > '/etc/apt/preferences.d/vivid-pinning' <<-EOF
Package: *
Pin: release n=vivid
Pin-Priority: -100
EOF
# add the vivid repository key
apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 3B4FE6ACC0B21F32
# update the repositories
apt-get update -qq
# install libminizip-dev (and dependencies) from vivid
apt-get install -y -q -t vivid libminizip-dev
fiAnd it seems that Travis CI like it. 😉 |
|
@illwieckz Props for creativity, it works! 👍 |
|
Just a thing, some shells does not accept to append to non existent files (so, the safer is to |
|
Just for fun, building xqf source tree with autotools autoupdate the file ------------------------------ po/Makefile.in.in ------------------------------
index 06a8cfe..fcd2c3b 100644
@@ -33,8 +33,7 @@ exec_prefix = @exec_prefix@
datadir = @datadir@
datarootdir = @datarootdir@
libdir = @libdir@
-DATADIRNAME = @DATADIRNAME@
-itlocaledir = $(prefix)/$(DATADIRNAME)/locale
+localedir = @localedir@
subdir = po
install_sh = @install_sh@
# Automake >= 1.8 provides @mkdir_p@.
@@ -80,7 +79,7 @@ INTLTOOL__v_MSGFMT_0 = @echo " MSGFMT" $@;
.po.pox:
$(MAKE) $(GETTEXT_PACKAGE).pot
- $(MSGMERGE) $< $(GETTEXT_PACKAGE).pot -o $*.pox
+ $(MSGMERGE) $* $(GETTEXT_PACKAGE).pot -o $*.pox
.po.mo:
$(INTLTOOL_V_MSGFMT)$(MSGFMT) -o $@ $<
@@ -108,7 +107,7 @@ install-data-no: all
install-data-yes: all
linguas="$(USE_LINGUAS)"; \
for lang in $$linguas; do \
- dir=$(DESTDIR)$(itlocaledir)/$$lang/LC_MESSAGES; \
+ dir=$(DESTDIR)$(localedir)/$$lang/LC_MESSAGES; \
$(mkdir_p) $$dir; \
if test -r $$lang.gmo; then \
$(INSTALL_DATA) $$lang.gmo $$dir/$(GETTEXT_PACKAGE).mo; \
@@ -142,8 +141,8 @@ install-exec installcheck:
uninstall:
linguas="$(USE_LINGUAS)"; \
for lang in $$linguas; do \
- rm -f $(DESTDIR)$(itlocaledir)/$$lang/LC_MESSAGES/$(GETTEXT_PACKAGE).mo; \
- rm -f $(DESTDIR)$(itlocaledir)/$$lang/LC_MESSAGES/$(GETTEXT_PACKAGE).mo.m; \
+ rm -f $(DESTDIR)$(localedir)/$$lang/LC_MESSAGES/$(GETTEXT_PACKAGE).mo; \
+ rm -f $(DESTDIR)$(localedir)/$$lang/LC_MESSAGES/$(GETTEXT_PACKAGE).mo.m; \
done
check: all $(GETTEXT_PACKAGE).potSince I build out of tree, theses changes are never committed. This autotools stuff needs to build the project to be able to commit the source, it's weird… |
|
@skybon: it's not a critical issue, but currently, |
|
Hi @skybon, it seems you miss something about GeoIP: https://travis-ci.org/XQF/xqf/jobs/67608335 😜 |
|
Hi @skybon, Two things:
Otherwise the rest seems ok to me. 😃 |
|
@jmallach it's you who had removed flags.tar.gz, but you were fooled by the very complex build system and .gitignore system. In autotools' age, We lose the flags because we use autotools so you are building inside versioned source tree. Also, I made before a comment about a versioned file So, I'm sorry, @jmallach, unless I misunderstood something, you made two mistakes because we are using autotools and because you are building inside versioned source tree. It's not your fault, it's autotools fault, so we need to get rid of autotools.
We've done all these mistakes only because we use autotools and we build inside the versionned source tree, because the autotools stuff is unreadable, and because the So,
|
| fi | ||
|
|
||
| # extract flag icons | ||
| rm pixmaps/flags/*.png |
There was a problem hiding this comment.
Here the flags were deleted if they are already there (not expected to be in the repository).
|
So this PR is fixing:
@skybon, can you re-add the flags so this PR will fix #156 too? 😉 |
|
Perhaps you could merge current toolchain first, this PR is already bloated as it is. |
|
OK. It seems I have to merge this PR. We can't wait more. With all the problems this PR revealed and all the problems this PR fixes, autotools is not a valid choice anymore. |
|
@skybon, just one last thing: It seems that |
|
Works as intended. Gamesxml2c is a target on its own. After compilation it processes the games.xml file and is discarded afterwards. |
|
Hmmm, yesterday it worked with checkinstall, not today, what happened… 😕 |
|
Hmm, it's broken with the |
|
Wow, something just recreated my whole ~/dev repository with an empty one, hopefully it was only a symlink, checkinstall is not safe at all. o.O
|
|
Kids, autotools do support out of tree builds just fine. What made xqf's build scripts complicated was the gettext integrating which was rather suboptimal ten years ago. That's not autotools fault per se. It's fine if you prefer the strange cmake language but please don't blame everything you don't understand on autotools. |
|
Hi @lnussel, glad to see you! I will not hide that I am not an autotool expert (and not a cmake expert, by the way), my goal and my interest is to continue to maintain XQF and to be able to do that, so anything that simplifies the procedure is welcome. If someone comes with a better autotools based build system or a better cmake based build system, it's ok if it's better than before. What I see is that I can understand the work done by @skybon, and that's not bad at all. 😉 If you have some suggestions in the future, feel free to talk about them before we merge some code. I said to @skybon that he must simplify the work of each others, it's the merge condition. So if in this cmake stuff you need something specifically to help you build OpenSUSE packages, please ask it to skybon. If something needs to be improved in the build system, he is now the one to ask. It's true there is many thing to clean up in this source tree, maybe I do not understand everything, but some things can not be kept as is if we want to move forward. 😄 Yeah, perhaps we are kids, but the project is alive and @skybon is doing good stuff (GTK3 is coming), kids are life. 😀 |
|
@lnussel Maybe I am not the best expert on Autotools and maybe it's possible to implement the same stuff with it. I don't know. However what I do know is that Autotools will give you much worse headache than a modern build system. And as I said, build system's main task is ease burden on developers. Feel free to rewrite old Autotools build system and prove me wrong. And no copy-pasted configure.ac / autogen.sh please. :P |
|
@skybon, just a tip to work in team successfully:
It's true in real life too. |
|
|
This PR also fixes #141. |
|
We probably got off the wrong foot, so I'm sorry and I concede. CMake can make things happen, however, and I'm looking forward to us not worrying about build process anymore. |
Now this is a huge patch which overhauls the whole XQF build process.
I have already explained at length why the current build system (GNU Autotools) needs to go. This patchset removes autotools support completely and adds CMake.
Key highlights:
How to build:
Flags (prefixed with -D)
This is a very extensive overhaul, may require some testing. Works for me but some bugs might remain.
Fixes #138 #141