Update driver install dir to follow cmake install prefix
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.
There seem to be build/test issues, I'll look into this.
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
OMG, many thanks @jkohnert ! However, the few graphic tests do not pass (on all platforms).
@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.
@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
test_delvarrnew and test_shmap do not pass on OSX (in addition to previous unrelated test that did not pass) This has to be investigated. test_delvarrnew says:
full path to exe not detected :(
/bin/bash: -quiet: command not found
note that /bin/bash does not exist on OSX.
Thanks again, @GillesDuvert; I'll take another look into this. Unfortuately, I do not have access to a MacOS maschine; I hope to get a clue, though. :grin: