Ticket #2371 (closed defect: fixed)

Opened 5 years ago

Last modified 22 months ago

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

Reported by: frankie Owned by: warmerdam
Priority: normal Milestone:
Component: ConfigBuild Version: svn-trunk
Severity: normal Keywords:
Cc: antonio

Description

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.

Change History

Changed 5 years ago by frankie

  • version changed from unspecified to svn-trunk
  • component changed from default to ConfigBuild

Changed 5 years ago by frankie

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

Changed 5 years ago by 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)

Changed 4 years ago by 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.

Changed 4 years ago by antonio

  • cc antonio added

Changed 22 months ago by rouault

  • status changed from new to closed
  • resolution set to fixed

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

Note: See TracTickets for help on using tickets.