Opened 16 years ago

Closed 13 years ago

#2371 closed defect (fixed)

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 (6)

comment:1 by frankie, 16 years ago

Component: defaultConfigBuild
Version: unspecifiedsvn-trunk

comment:2 by frankie, 16 years ago

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

comment:3 by Even Rouault, 16 years ago

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)

comment:4 by Even Rouault, 15 years ago

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.

comment:5 by antonio, 15 years ago

Cc: antonio added

comment:6 by Even Rouault, 13 years ago

Resolution: fixed
Status: newclosed

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.