Initial attempt to add separate GDL_LIB_DIR for plplot drivers

[opoplawski]

Current output:

+ export PLPLOT_DRV_DIR=/home/orion/BUILDROOT/gdl-1.0.2-1.fc38.x86_64/usr/lib64/gnudatalanguage/drivers
...
    Start 80: test_dynamic_drivers.pro

80: Test command: /home/orion/fedora/gdl/gdl-1.0.2/build/src/gdl "-quiet" "-e" "if execute('test_dynamic_drivers') ne 1 then exit, status=1"
80: Working Directory: /home/orion/fedora/gdl/gdl-1.0.2/build/testsuite
80: Environment variables: 
80:  LC_COLLATE=C
80:  GDL_PATH=/home/orion/fedora/gdl/gdl-1.0.2/testsuite/:/home/orion/fedora/gdl/gdl-1.0.2/src/pro/
80:  GDL_STARTUP=
80:  IDL_STARTUP=
80: Test timeout computed to be: 3600
80: 
80: *** PLPLOT ERROR, ABORTING OPERATION ***
80: plInitDispatchTable: Could not open drivers directory, aborting operation
80: % Compiled module: TEST_DYNAMIC_DRIVERS.
80: % Compiled module: SURFR.
80: % Compiled module: SCALE3D.
1/1 Test #80: test_dynamic_drivers.pro .........   Passed    0.48 sec

Seems like we still need to deal with:

80: *** PLPLOT ERROR, ABORTING OPERATION ***
80: plInitDispatchTable: Could not open drivers directory, aborting operation

despite the test succeeding? Or is that just it trying to open /usr/lib64/gnudatalanguage/drivers which doesn't (yet) exist?

[opoplawski]

That may be it, because once installed:

$ gdl
installed at: /usr/bin/../share/gnudatalanguage
  GDL - GNU Data Language, Version 1.0.1 Git
- For basic information type HELP,/INFO
- Default library routine search path used (GDL_PATH/IDL_PATH env. var. not set): +/export/home/orion/idl:<IDL_DEFAULT>
- Using WxWidgets as graphics library (windows and widgets).
- Using local drivers in /usr/lib64/gnudatalanguage/drivers
- Please report bugs, feature or help requests and patches at: https://github.com/gnudatalanguage/gdl

[GillesDuvert]

@opoplawski see my comment on #1478.

So apparently plplot on Fedora is compiled with dynamic drivers --- good. Perhaps the first message plInitDispatchTable: Could not open drivers directory, aborting operation is harmless but needs to be investigated.

However the whole setup described in #1478 was set to provide our drivers and have them automatically found in all the MacOSX bundles and Windows installers, not mentioning individual installs of gdl. Wich works perfectly and saves us a lot of concerns.

This is quite contradictory with the installation of gdl at system level by, e.g., the Fedora distribution, and I expected some troubles indeed.

I suppose we could just have a test ( #ifdef ) that would basically say 'this is a distro compilation and the location of gdl and consorts is fixed by me, the distro maintainer' so that a number of locations (GDL_LIB_DIR only?) can be passed to the program.

I'm concerned also by the location of the PROJ -related data (/usr/local/share/gnudatalanguage/resource/maps) etc.

[GillesDuvert]

Note in passing: since the GH checks (continuous integration) do not test the installer or OSX bundles they can succeed but the installers etc WILL NOT WORK.

[GillesDuvert]

@opoplawski thanks (in passing) for your dedication!

[GillesDuvert]

Hmmm, let's check this calmly.

[GillesDuvert]

Dear Orion, it seems to me this changes are perfect for your purpose, and in general for packagers whose distribution must put all .so files in /lib${LIB_SUFFIX}, but will not permit to get the location of drivers (staying in this GDLLIBDIR/...) from the location of the excutable (in INSTALLDIR/bin) for nearly everybody else, including our "dumb" installers, where driver location must be deduced from INSTALLDIR/bin/ only.

In other words, unless a specific keyword triggers a special behaviour, the drivers location need to be found only relatively from the location of the executable.

So I suggest that the specific installation of drivers in /lib64/gnudatalanguage/drivers by a distro maintainer (and the value of GDL_LIB_DIR in your fix) must be forced in gdl.cpp by an #ifdef, and this #ifdef shall be triggered by a specific -DXXXX in the cmake, say -DGDL_LIB_DIR="/lib64/gnudatalanguage", which can be tested as non-null in the code, and subsequent actions taken.

Additionnaly I suppose this is where the libgnudatalanguage.so shoudl go if gdl is built as a python module.

Would you try such a scheme?

[olebole]

On Debian, the proper path would be (complete) /usr/lib/${DEB_BUILD_MULTIARCH}/gnudatalanguage/drivers ( /usr/lib/x86_64/gnudatalanguage/drivers), i.e. with an additional subdirectory level. Just a ${LIB_SUFFIX} doesn't work for us. Setting the -DGDL_LIB_DIR=lib/${DEB_BUILD_MULTIARCH}/gnudatalanguage work work for us.

[GillesDuvert]

Hi thanks for your guidelines.
I think it is not proper to add

${DEB_BUILD_MULTIARCH}

or

${LIB_SUFFIX}

in GDL code itself.
I propose a commit where @olebole would do
cmake (..) -DGDL_LIB_DIR="/usr/lib/${DEB_BUILD_MULTIARCH}/gnudatalanguage/drivers" ...
and @opoplawski would do
cmake (..) -DGDL_LIB_DIR="/usr/lib${LIB_SUFFIX}/gnudatalanguage/drivers" ...
To build GDL.

And, if GDL_LIB_DIR is not defined (the default), the location of drivers is deduced from the location of the executable (as it is now for OSX, Windows, and user-managed installations)

Would that be OK?

[olebole]

Yes, this is fine for me.

[opoplawski]

That sounds good to me.

[GillesDuvert]

replaced by (merged) #1486 (do not know how to, I quote "Add more commits by pushing to the libdir branch on opoplawski/gdl." )

Please test?