Talk:Building FlightGear - Devuan

From FlightGear wiki
Jump to navigation Jump to search

Hello,

I didn't try these instructions recently, but they proved very useful when I first built FG, so thanks for this!

Two remarks:

  • plib being dead upstream, what is the point of building it? I've always used the Debian one for this without any problem (well, actually a fixed local version for joystick deadband management; sid now has the fix at last, but not stretch, unfortunately).
  • Current FG from next requires these two packages when building with Qt support: qtdeclarative5-private-dev and qml-module-qtquick2 (since FG commit 3a8d350, committed on 2017-09-26).

--Rominet (talk) 18:31, 3 October 2017 (EDT)

Oy!
a) yw
b) TBH I am not certain whether the plib step is required anymore, will look into that for the next update (for which I hope to have some spare time in the upcoming days). Last time I've checked it was required since Melchior's commits never went into a release and hence never reached Debian.
c) Thanks for reporting the newly required packages, saves myself some research!
--Flughund (talk) 22:27, 3 October 2017 (EDT)
My pleasure. :)
It is true that plib svn has a significant amount of code changes that are not in the orig tarballs used by the Debian packages (at least stretch and sid for sure, probably several older releases too). OTOH, the Debian packages have two security fixes (for CVE-2011-4620 and CVE-2012-4552) and the corresponding patches never got applied in plib's svn repository. :/
--Rominet (talk) 03:27, 4 October 2017 (EDT)
The plib repository used by download_and_compile.sh now has the security fixes, on top of the latest PLIB svn commit (I diffed Clément's commit 1b3b3e1d and the official plib 'trunk', the only differences are a 'version' file added at the repo root and the CMakeLists.txt files added by Clément).
--Rominet (talk) 04:02, 5 October 2017 (EDT)
Yay, that's great news! Thanks a lot! For Saturday they're predicting rain so I probably will have time far an update.
--Flughund (talk) 12:06, 5 October 2017 (EDT)
Do you think it'd be possible to alter the version to 1.8.6 in that repo, too? As suggested by Melchior in https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html
AFAICS this would mean altering file "version" and file "src/util/ul.h" line 157.
--Flughund (talk) 21:02, 6 October 2017 (EDT)
Mmmm, I read that mail and discovered things indeed, but I don't know if we can morally do that. :) Since this is not the official plib repo... it's always very delicate when one has to at least technically fork a project that is not maintained anymore. :/ Otherwise, I have that bugfix from 2015 too, related to joystick deadband management. Maybe some #define PLIB_FLIGHTGEAR_VARIANT would be cleaner...
--Rominet (talk) 05:41, 7 October 2017 (EDT)
I don't think we run into problems regarding morality: https://sourceforge.net/p/plib/mailman/message/28580157/
Ah, interesting that bug. Always had the feeling something was wrong with the dead band of my simple joystick. Though not sure whether it's the stick itself or if that was because of this bug. Will try that as soon as I rebuild FG.
--Flughund (talk) 06:16, 7 October 2017 (EDT)
Yeah, my use of the word “morally” was a bit of a joke, of course. Indeed, plib's author gave FG devs much latitude, but no one so far, TTBOMK, said “this is plib-ng [whatever the name] and I am maintaining it.” And distro packages still refer to the historic plib, and FG is not its only user (there is at least TORCS, maybe others)...
I'll ask on flightgear-devel.
--Rominet (talk) 07:58, 7 October 2017 (EDT)
Done, see here.
--Rominet (talk) 08:50, 7 October 2017 (EDT)
I really appreciate this! I am a total noob when it comes to coding or handling code in any way. And the sed thingy in the plib section bothers me for a long time now. On my local copy of this article I already have applied the changes for the new repo but due to git and cmake it is even more hackish than before. So I was afraid to change it online and preferred to wait and hope for a better solution. Oh, and yes, your assumtion was correct, I am Alex D-HUND AKA flughund AKA debdog.
--Flughund (talk) 12:32, 7 October 2017 (EDT)
You're welcome. I'm a bit surprised things get that ugly just because of the switch to Git and CMake; you could maybe post your command sequence here. Also, since Clément's repository only *adds* a CMake setup and the security fixes, you should be able to use the old build method too, just replacing an 'svn co' command with a 'git clone' one (and changing the repository address, of course).
BTW, if you want to return the repository to its pristine state, there are two useful commands: 'git reset --hard' to restore files tracked by Git to their state in HEAD (this is equivalent to 'git reset --hard HEAD') and variants of 'git clean -df'. (use -n to see what would be done without doing it, and see 'git clean --help' for other options). This avoids having to clone the repo more often than needed...
--Rominet (talk) 03:21, 8 October 2017 (EDT)


Well, not exactly ugly, just more hackish and even less user friendly:
cd $FG_SRC_DIR
git clone https://git.code.sf.net/p/libplib/code libplib.git
cd libplib.git
echo "1.8.6" > version
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
git add version src/util/ul.h && git commit --message "Increase tiny version to 6."
mkdir $FG_SRC_DIR/build-plib && cd $FG_SRC_DIR/build-plib
cmake -D CMAKE_INSTALL_PREFIX:PATH="$FG_INSTALL_DIR" $FG_SRC_DIR/libplib.git
make -j2 && make install
--Flughund (talk) 05:40, 8 October 2017 (EDT)
Well, there are a few lines but I don't find it much worse than the svn way. The line with 'git add' can be shortened like this:
git commit -am 'Increase tiny version to 6.'
(-a adds all modified files that Git wasn't told to ignore)
Also, this commit is no more necessary than with svn, where you don't commit the change... But with the commit, the repo can be updated with:
git pull --rebase
which automatically reapplies your commit on top of the updated origin/master. So, it's nice to have. Otherwise, without the commit, the repo would have to be updated with something like:
git reset --hard && git pull
echo "1.8.6" > version
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
or more elegantly:
git stash save Update-tiny-version-number-to-6    # Or simply 'git stash'
git pull
git stash pop
Also, in my FG build script I use 'make -j$(nproc)' to avoid hardcoding the number of parallel jobs.
--Rominet (talk) 06:14, 8 October 2017 (EDT)
Of course, I realize the instructions in this page are not oriented in the "update the repo" way, which is probably a good idea to keep them simple. The methods given here for updating the repo were mainly FYI.
--Rominet (talk) 06:55, 8 October 2017 (EDT)
Also, since FG works reasonably well with Debian's PLIB (maybe missing a few things added by Franz Melchior as you pointed out, but nothing very serious AFAIK---well, the joystick bug can be annoying if you try to set a dead-band with jscal, but it's fixed in Debian unstable), you can say the plib building step is optional and people who find there are too many commands to run can just install libplib-dev...
--Rominet (talk) 12:06, 8 October 2017 (EDT)