gdl icon indicating copy to clipboard operation
gdl copied to clipboard

Update driver install dir to follow cmake install prefix

Open jkohnert opened this issue 1 year ago • 5 comments

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 avatar Mar 29 '24 15:03 jkohnert

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

jkohnert avatar Mar 29 '24 17:03 jkohnert

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

jkohnert avatar Mar 31 '24 22:03 jkohnert

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

GillesDuvert avatar Apr 06 '24 18:04 GillesDuvert

@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 avatar Apr 08 '24 06:04 jkohnert

@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

jkohnert avatar Jul 14 '24 15:07 jkohnert

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.

GillesDuvert avatar Sep 12 '24 20:09 GillesDuvert

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:

jkohnert avatar Sep 15 '24 09:09 jkohnert