gnudatalanguage / gdl

GDL - GNU Data Language
GNU General Public License v2.0
274 stars 61 forks source link

Update driver install dir to follow cmake install prefix #1792

Open jkohnert opened 5 months ago

jkohnert commented 5 months ago

When defining GDL_LIB_DIR, the install process does not take into account a set CMAKE_INSTALL_PREFIX. I implemented this patch as part of the Arch-Linux AUR package, since having *.so files in /usr/share/ is considered bad packaging by the Arch-Linux guidlines.

Once applied, setting GDL_LIB_DIR is compatible to GDL_DATA_DIR (f.e. lib/gnudatalanguage, and share/gnudatalanguage), and both locations will respect a set CMAKE_INSTALL_PREFIX (f.e /usr/), so the install dirs will be f.e. /usr/lib/gnudatalanguage, and /usr/share/gnudatalanguage, respectively.

jkohnert commented 5 months ago

There seem to be build/test issues, I'll look into this.

jkohnert commented 5 months ago

I've now reworked this whole thing.

The basic idea is to always use the configurable $INSTALL_PREFIX/lib/gnudatalanguage as driver install dir. We determine the location of installed *.pro-files (and some other things) as being installed in locations we can get from the executable path if installed in some bin directory. The same logic should be applied for drivers as well.

I added some CMake statements to also be able to use built drivers from the build-dir directly in tests by copying the *.driver_info files to the build-location if we set GDL_DRV_DIR.

The logic should work for Gnu-install-dir-aware installations as well es MacOS, or Windows.

I included some Clang-Tidy related changes as well. :innocent:

BTW: Are there any plans to include C++17, or C++20 dependent code? The return type of lib::PathSeparator() and alike could possibly be changed to constexpr std::string_view or something like that, but that would require C++17, at least.

Best, Jan

GillesDuvert commented 4 months ago

OMG, many thanks @jkohnert ! However, the few graphic tests do not pass (on all platforms).

jkohnert commented 4 months ago

@GillesDuvert thanks for having a look at this. The failing tests were obviously unintended and I actually thought, I had fixed the problem. I'll have another look as soon as I have time.

jkohnert commented 1 month ago

@GillesDuvert I think, this is OK now: There are still some tests failing for MacOS, but they seem unrelated, at least to me. For tests to run on Linux/Mac the patch now sets the "GDL_DRV_DIR" environment variable. I'm not sure, if this is OK, if not, I'll have to rework the include paths search to consider the paths the compiled files are located in...

For now, I consider this OK and ready for review. :smile:

Best, Jan