Split binary/xq install directories for modules

Bug #862089 reported by Chris Hillery
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zorba
Fix Released
High
Chris Hillery

Bug Description

This is at the request of the Fedora package maintainer.

Currently Zorba installs the .xq (and .xsd) files for schemas and the .so/.dll files for module external functions into the same directory, by default share/zorba-VERSION/modules. This does not meet Fedora packaging requirements, which state that any platform-dependent files such as .so files must go into lib/lib64 directories. Ideally, non-platform dependent files such as .xq and .xsd should be filed in share.

There is another problem with the above scheme: since this directory is where non-core modules will install themselves also (and the only place Zorba will look for them), they are implicitly tied to Zorba's version number even though they should have independent versioning.

The proposal is to split this into a total of four directories: platform-dependent/platform-independent, and Zorba-version-specific/non-Zorba-version-specific (ie, core modules vs. non-core modules). So, for instance:

CMAKE_INSTALL_PREFIX/
     share/
          modules/
          core-modules/
               2.1/
     lib64/
          modules/
          core-modules/
               2.1/

where "2.1" is the Zorba version.

The easy way to do this would be to simply put all of the above on the default module-path, and change the install process to put everything in the right places. One downside to this is that it means Zorba will look in many wrong places when doing any URI resolution and when loading .so files - it knows it is looking for (say) an .xq file, but it will look in the two lib/ directories as well because they're all on the same module path.

A better way to do this would be to separate the concepts inside Zorba as well, and have a "URI Path" for all URI resolution which is separate from the "module path" which is used for loading external function libraries. Zorba could do that for itself easily enough. The only issue is what would be the interpretation of --module-path (and the corresponding C++ API function) - would that be a backward-incompatible change?

Related branches

Chris Hillery (ceejatec)
Changed in zorba:
assignee: nobody → Chris Hillery (ceejatec)
importance: Undecided → High
Changed in zorba:
milestone: none → 2.1
Changed in zorba:
status: New → Fix Committed
Chris Hillery (ceejatec)
Changed in zorba:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.