Removing autotools support #62
Conversation
|
You might want to go through the XSLT files in the xslt folder – autotools and cmake use different sets of files, thus dropping autotools will render some XSLT files obsolete. |
|
We are not going to drop support of any platform with active users of navit. It looks like maemo cmake build problem is related only to png conversion stage, see http://talk.maemo.org/showpost.php?p=1277788&postcount=631 To fix the issue, we'll need build logs of a successful build with autotools and a broken cmake build in the same environment, and scripts used to configure the build. I think the proper place to discuss it would be a separate ticket on trac.navit-project.org. |
|
Kudos for finally going through with this! Maintaining two build systems in parallel just does not make sense in the longer run. |
|
I'm not a developer but one of the Navit users on the maemo platform.
Months ago i put these building scripts written by the guy who used to
build Navit for maemo here
https://github.com/navit-gps/navit/tree/ernesto75/build-scripts. He managed
to build it with autotools but not with cmake. I hope someone can find a
workaround for cmake
|
|
@ernesto75: I personally cannot fix the Maemo build, as I do not have the build environment set up. However, if someone tries building for Maemo with CMake and runs into problems, I'll be glad to help. In that case, it's best to open a bug on http://trac.navit-project.org/ describing the problem. |
|
@sleske actually you can see the compilation output here : https://circleci.com/gh/navit-gps/navit/122 |
|
I agree. The current issue seems related to wrong scratchbox http://maemo.muarf.org/tablets-dev/maemo_dev_env_downloads/ File: maemo ubuntu lucid desktop sdk virtual image final.7z And try to build with cmake
|
|
Ernesto75, we seem to miss 'debian' directory from https://github.com/navit-gps/navit/tree/ernesto75 . It should contain important files needed for compilation. For example, there expected to be 'rules' file which probably contains the actual compile script. Can you share your 'debian' directory? |
|
This is the dropbox link to the debian directory used for maemo Il 07/01/2016 20:30, mdankov ha scritto:
|
|
ernesto75, thank you! But it looks like it's autotools build scripts. Do you have a copy of debian directory which results in failed build attempt on navit-data package, like it was described in posts you gave us links to. |
|
No. I just know they tried but not working for many reasons. Quoting:
|
|
ernesto75:
That should not be necessary. The Debian tools do have support for CMake, not just for autotools. Actually, the official Debian package ( https://packages.debian.org/sid/navit ) was converted to use CMake recently. That can hopefully serve as an example. |
|
I've got a few errors building in the ubuntu image, most of them are related to the image being quite old. I was able to resolve all of them by running 'apt-get update' and 'apt-get install' for some selected packages, most notable ones are autotools and libtool. Though maybe 'apt-get upgrade' would be more correct. I had to install a few packages as well to fulfil dependencies, as reported by dpkg-buildpackage. Though I'm unsure if espeak is actually needed during build. During the build, I've got a error about missing libfreetype6-navit-dev package, which is marked as required for the build. I'm running now the build with libfreetype6-dev, with the -d key passed to dpkg-buildpackage. Is there some known problem with system-supplied libfreetype? Where then can I get the proper (patched?) one? No fatal errors so far, but the build in qemu goes to take a while... |
|
ok, build has finished, but it actually was an i386 build. I forgot to issue sb-conf select FREMANTLE_ARMEL beforehand. And it looks like I can't install any dependencies after that command. Any ideas? |
|
I remember some system related issue about freetype. You can find patched
freetype here http://bokomoko.de/~rd/maemo/unstable/
for details read
https://talk.maemo.org/showpost.php?p=1017888&postcount=508
|
|
For the installation of espeak i don't know. Should be there
http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/libespeak-dev/1.46.27/
|
|
I have added following lines to the /etc/apt/sources.lst while in FREMANTLE_ARMEL mode: Now 'apt-get install libdevil-dev libespeak-dev libimlib2-dev libfribidi-dev libpq-dev librsvg2-bin' doesn't complain on inability to find packages, but it does on lots of unresolved dependencies in the system. It suggests to run apt-get -f install, but it fails too. Attempted to install deb file manually: Looks like i'm missing something... |
|
It appears the following lines being added to /etc/apt/sources.list, break the dpkg system of scratchbox. Am I expected to download deb's to satisfy build dependencies and install them with dpkg? Or is there some other way? |
|
Maybe try this: EDIT: You can now just use the following sources.list entry: deb http://repository.maemo.org/ fremantle/4bc37c7c77ebe90177c050b805a8dc79 [sbox-FREMANTLE_X86: ~] > sb-conf select FREMANTLE_ARMEL
|
|
Hi! People on maemo irc channel suggested following sources.list: and following /etc/apt/preferences: After that, i had to run I have manually installed libfreetype6-navit packages from bokomoko. But I was also suggested at maemo irc to switch to ccsu-thumb instead of scratchbox, see http://mg.pov.lt/maemo-irclog/%23maemo.2016-01-10.log.html#t2016-01-10T00:51:26 and to "add navit it to extras" http://mg.pov.lt/maemo-irclog/%23maemo.2016-01-10.log.html#t2016-01-10T00:54:52 Maybe ccsu-thumb would be better integrable with circleci. And of course we'd be happy to be included in the official repo. |
|
Cool! Thanks for the effort. So now you can build with autotools and also
|
|
Up to now, I have managed to build R6024 with autotools. Did not test the built package though. Build of current code with cmake has failed, because currently gtk_drawing_area works through cairo, and it was never tested if n900 version of cairo is supported. I guess, it at least has cairo. I'm now building 7410ba6, which i expect to be the last revision clean from that transition. At navit irc channel, _rd shared following infos:
|
|
Another build stop while building gtk_drawing_area, probably it's dcc80ed, require qt > 4.7 |
|
Actually, here we are going to be sure if autotools removal doesn't break anything, so i'm now reverting to the head of ernesto75 branch (R6024), attempting to build it with cmake. I do not think graphics problems are somehow in relation with makefile generator chosen (cmake/autotools). So we'll have to deal with graphics (and, probably, other) incompatibilities in separate branch(es). |
Yes, that was me :-/. However, as far as I can see, the transition to Cairo should not be a problem for N900. GTK+ has used Cairo internally for a long time (at least since V2.8, from 2005), so if gtk_drawing_area worked on N900 before, it should work with Cairo, too. At any rate, if the autotools build works, the use of Cairo cannot be the problem. If you can share the exact build error, maybe we can solve this together. |
|
sleske, i guess, Cairo problem is most probably just my fault to install appropriate development library in the build environment. I do not have a single successful cmake build yet, and concentrating on achieve it. I had also to disable qt_qpainter graphics for now. Looks like cmake detects QSvgRenderer presence, but does not properly configure its paths. At least, i have manually located that file in /usr/include/QtSvg, but during build i get: I'll also have to verify what autotools build thinks about QSvgRenderer presence on this platform. |
|
I currently have successfully built navit-armel with plain cmake, and navit-i386 deb packages. Though for now, I have qt_qpainter and gui/qt switched off, and using an older version of code from ernesto75 branch to keep away from gui_gtk switch to cairo. Now building deb packages for armel with cmake. Armel builds are very slow. @sleske, i think cairo in general is not of a big concern. Build fails on macro CAIRO_ANTIALIAS_GOOD, which is defined since 1.12, but maemo has cairo 1.8. We can check cairo version at build time or just switch to CAIRO_ANTIALIAS_DEFAULT, which is said to be typicaly equivalent to the former, see http://www.cairographics.org/manual/cairo-cairo-t.html#cairo-antialias-t. |
|
Amazing results! I am glad for maemo community to still have the possibility to install a Thank you again for your work. Il 16/01/2016 08:33, mdankov ha scritto:
|
|
Ok, i now have some deb files for testing: http://www.navit-project.org/~tryagain/maemo/ There's also the source tarball with cmake-aware debian folder. I have changed option to build only two size versions of images to make the build run faster, so don't be surprised by blurred imagery. Though, one maybe can use an old data package or put png images directly to /opt/navit/share/navit/xpm. Uhhh, i'll have to deal with that path. Now will attempt to switch to a more current code version. |
|
Installed the armel debs (except the data one, which i kept from other
|
|
@ernesto75 , now i have success pushing our git master head source to the maemo official autobuilder, and it even has built with cmake and propagated to extras-devel repo. I also see there's a patch for navit_shipped.xml laying in debian/patches.orig. I did not test it yet, but have a few questions regarding it.
I still have graphics/qt_qpainter and gui/qml disabled for maemo builds. Do you think they are indeed useful on n900? |
|
Great! Is the latest one with cairo? Im going to test it asap! Don't know about patch enabling two mapsets at the same graphics/qt_qpainter i tried once from bokomoko repo to see if improve performance but with internal gui didn't appreciate improvements, maybe with other guis? qml gui also i tried from bokomoko it seems buggy and unusable (discontinued developing?) So i can wait for that.
odometer persistent_odometer_1 0.000000 0.000000 0 0.000000 navit.layout=navit.layout[@name=="Car"]; |
|
The version in maemo repos working good! I just noticed a wrong icon for
|
|
@ernesto75, cool. |
|
I put my config files, with some screenshots about the wrong car parking |
Yes, parking.svg currently contains a "<text>" element to render the "P", with font Bitstream Vera Sans Bold. It should be simple to convert this to a vector path (in Inkscape, "Path / Object to path"). I'll see if I can fix this. |
|
@mdankov @ernesto75 As for the OSD configuration – this is definitely something that needs to be worked on, but I think this is a separate discussion and it concerns a few more platforms. (For example, the default Android OSD layout could also use an overhaul – I already have some ideas on that.) I'd suggest opening a ticket for the OSD – the purpose of this merge request is to ensure we can build all ports with the cmake toolchain. |
|
What is the current state of this issue? It would be great if we could finally drop autotools. |
|
Maemo version now can compile with cmake. Just a secondary issue to fix is What is the current state of this issue? It would be great if we could — |
I'm afraid I don't understand - could you explain what you mean by "fix the push to maemo repos"? Does Maemo not just pull the source code via git or similar?
Could you explain what "slow rendering" has to do with this ticket? This is about changing the build system. Changing the build system should not change the compiled code - the compiler invocations should remain the same, they are just generated differently. If the switch automake -> cmake produces different code, we should investigate that. |
|
Is there something else to do for the original topic, now tomtom is converted to cmake ? |
Conflicts: navit/Makefile.am navit/xpm/Makefile.am po/Makefile.am
|
Updating the branch to match the current trunk |
|
As all conflicts have been resolved, are there any other issues that need to be resolved? |
|
@jandegr Thanks for merging! |
jkoan
added
the
i18n
As per http://trac.navit-project.org/ticket/1341 we are removing autotools support.
I'm opening this PR for a collective review to ensure I did not miss something.