GDAL plugins path is not coherently managed in the building system: please avoid embedded paths.

[frankie]

It would be better introducing an --autoload=/custom/path for the plugins directory instead of embedding a fixed path as in the GDAL/OGR cores (currently /lib/gdalplugins). The GDAL_DRIVER_PATH/OGR_DRIVER_PATH environment variables can be retained as well, but apparenly thery are not documented out of the source code (if I'm not missing something).

This is the same approach used in the grass configuration script in frmts/grass and it would allow packager to customize without patching sources. Patching is required in order to have multiple paths for different cohexisting libraries.

[frankie]

The same considerations apply for <prefix>/share/gdal

[rouault]

Francesco, any patch for that ?

As for the <prefix>/share/gdal, are you refering to INST_DATA ? This one is defined in GDALmakeopt.in as @datadir@, so I guess that ./configure --datadir=XXXXX should solve the issue (I haven't try though)

[rouault]

Some extract of a discussion on IRC :

[19:54] <enrico> FrankW: the debian changelog says that I should encourage upstream to take a better approach and mentions gdal bug #2371 :)
[19:54] <gdaltrac> Ticket #2371: GDAL plugins path is not coherently managed in the building system: please avoid embedded paths., http://trac.osgeo.org/gdal/ticket/2371
[19:54] <EvenR> I can understand the reason for the debian maintener's suggestion 
[19:54] <FrankW> So can I.  So someone should write an RFC and volunteer to do the work.
[20:01] <EvenR> http://patch-tracking.debian.net/patch/series/view/gdal/1.5.2-3/gdalpaths
[20:01] <EvenR> but we can't apply that as such
[20:01] <crschmidt> EvenR: yeah, hence my comment that it's a hack :)
[20:02] <FrankW> I'd like any changes in this area handled via an RFC for broader discussion.
[20:02] <FrankW> I do think the plugin management is due for versioning, and greater transparency (perhaps via gdal-config).
[20:03] <enrico> FrankW: I'd say that once you let the distribution maintainer set the path in ./configure --something and let gdal-config show the path that was set, you should be allright
[20:04] <FrankW> I do not agree that is a sufficient improvement to plugin path management.

[rouault]

Plugin loading now looks for GDAL_VERSION_MAJOR.GDAL_VERSION_MINOR subdirectory. So I guess it is no longer an issue