Update driver install dir to follow cmake install prefix

[jkohnert]

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]

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

[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. 😇

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]

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

[jkohnert]

@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]

@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. 😄

Best, Jan

[GillesDuvert]

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.

[jkohnert]

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. 😁

[GillesDuvert]

@jkohnert :
I've been alerted by @opoplawski last comment in #1654 on the probable obsolescence of plplot (obvious considering the fact that all our bug reports of the last 4 years are still pending). --- I'm not complaining, obviously nobody seemed interested in maintaining the whole package. Me included.
However, in the sake of GDL, and given that I've considered this already for a long time, I've worked and now I've a PR at hand that removes entirely the dependency to plplot, and thus the need for a driver dir. I just applied the program in #1654 (comment) .
I intend to make this the new version of GDL, after a few more patches to our 'barebones plplot'. I suspect most of the intent of your PR disappears in this case?
You also corrected expressions like string(".") in {"."}. Being still uneasy with C++, what are the advantages of the latter?
Best

[jkohnert]

@GillesDuvert I also sent a patch to them being unresponded to neither in github nor sourceforge. There seems liitle to no activity in the project; so I'm not sure if the package is still maintained, too. If you're going to drop the dependency, this PR can be closed.

Those other changes your mention are only some small efforts to modernise the code base. string(".") shall (now) be written as {"."} according to Clang-Tidy and I changed the lines I stumbled upon as I think it's a good idea to keep the codebase in sync with the moderinsations of the language.

Since I'm using CLion here, such things are marked in the IDE and can be fixed easily. But it's not worth keeping this PR just for some moderinsations; I could make another PR doing things like that. 😁.

[GillesDuvert]

OK, no plplot dependency anymore -- thanks anyway, @jkohnert . Closing.