configure deprecation/removal

[tsteven4]

We intend to cease support for configuration using autotools, i.e. configure.ac, configure, Makefile.in, config.h.in will go away. The preferred configuration method will be to use qmake.

@jspricke Would you be willing, and do you have a process to do an experimental build from the HEAD of the master branch, or d7a922d0e14d69a318ee91795b43d16c160a422f, using qmake instead of configure? configure is still in the repository but I want to know if you will have any issues when it disappears. I am not suggesting this build ever goes anywhere beyond the experiment until we do a release in the future (unlike 1.7.0+ds-5 which I hope is distributed). I am trying to flush out issues the removal of configure might cause before we do a release and find out after the fact that we are causing packagers issues.

Some of the common needs of packagers should be better supported with qmake than they were with configure, specifically the use of system libraries for zlib, shapelib and libusb-1.0.

I'm not sure what is up with the Debian x32 build, it seems to be some issue with configure. Hopefully qmake will solve that issue.

If your doing cross-compiles things should work if you use the correct qmake, e.g. /usr/bin/s390x-linux-gnu-qmake instead of the native /usr/bin/qmake. I have done some cross-compiles, but in general I don't have a way to test them.

There is a short description of the process here: https://github.com/gpsbabel/gpsbabel/blob/master/INSTALL

Thanks for any help you can give us.

[jspricke]

I did a quick test with the current master and it works fine. The work in progress changes are here: https://salsa.debian.org/debian-gps-team/pkg-gpsbabel/-/commit/a56de08514dd919c41e8adeb81dca349294c7a67 (note that it doesn't work with the 1.7.0 version this is based on, will clean it up once a new gpsbabel is released).

[tsteven4]

@jspricke Thanks for the test. It is encouraging.

I have been looking over the debian build and I believe debian is not distributing the gpsbabel translation files. Getting all the translation files distributed has been a common issue on linux. For the gui (gpsbabelfe) you need gui/gpsbabel_.qm and gui/coretool/gpsbabel_.qm in addition to the Qt supplied translation files. The cli (gpsbabel) doesn't support translations. Without the translation files everything is in english. With them automatic translation of known text occurs based on the locale.

Distributing the translations is half the battle, the other half is having the application (gpsbabelfe) find them. There are two related PRs, #386, #391, and a history of patching by various distributions. These PRs share a common base, 391 adds an install target for the GUI. At this time I don't think the install paths provided by 391 are flexible enough, for example Fedora puts the gpsbabel translation files in /usr/share/qt5/translations, not /usr/share/gpsbabel/translations. I think having an install target that supports all the distros is going to be difficult due to distros distributing different sets of files in different locations. Also some distros distribute files they create or modify. At the same time I would like to avoid missing files and common patches, e.g. the location of gmapbase.html and the location of the translation files.

[jspricke]

Both translation dirs seem to be used in Debian and I did not find information which to prefer. Maybe @bzed has an opinion here? An install target would be great. Some more whishes:

• Generate the .qm files during compilation instead of having them in git.
• Options to build gui and documentation with the default make target.

[bzed]

@jspricke sorry completely missed that you've mentioned me here. Will have to look into the issue, but installing translations and/or generating them is not an issue, but to be honest I assumed that make install will install everything :)

[robertlipe]

Configure has been gone for a long time now. Closing.