On Sun, 2021-01-31 at 11:39 +0100, Jiri Daněk wrote: > I remember hearing somewhere that the option -DSYSINSTALL_BINDINGS > in > Proton is deprecated or should be considered deprecated.
You may have heard that from me personally, but it's not been discussed here on the qpid user list! For those who do not know this - this option switches between different ways to lay out the installed python and ruby libraries in the install area: * With -DSYSINSTALL_BINDINGS the build system tries to figure from the python/ruby executable found by cmake where the place that site- packages (and the equivalent for rubygems) should be installed and put the results of 'make install' there. The advantage of this is that you can just run 'make install' and then immediately use the libraries from python/ruby with no messing with the python sys.path. * The default actually is without -DSYSINSTALL_BINDINGS. This puts the bindings in <INSTALL>/lib[64]/proton/bindings/(python|ruby) which is a place where no installation will look without having it set up so is more-or-less useless! For quite a few release (I think, several years at this point) we have produced python packages and ruby gems as the primary output of the build. whilst still (for some tortured back compatibility idea) installing the files in the install area. My preference would be to completely stop this install as it confuses what is the primary product. The packages are completely as good as installed files - in fact better, because they can be installed in any setup according to its configuration. > > I am confused about this, for two reasons. First, this is essentially > what > any RPM/DEB packaging relies on when packages are built. This is just an artifact of the current package building process. The "correct" way (as in what you need to do to package something from PyPI) is to install the created package in the build phase of the package build (using somehing like "python setup.opy install") then to oacakge up the resulting files. I expect there is a similar process for ruby gems, but it's not something I know a lot about. > Second, Dispatch > depends on the unpacked Proton Python build during ctest testing in > development, not on the wheel. Again this is purely an artifact of how it is currently done, not how it "should" be done! To me it makes a lot more sense to do all testing from a virtual python environment with exactly the correct (and predicatably versioned) packages installed - really the way the tox does its testing. > > I did not find any notice or mention whatsoever that - > DSYSINSTALL_BINDINGS > is deprecated. As I said easlier it's not deprecated, but then I'm not sure it has to be to make this change as it does not affect library users. > > Can anyone please clarify? Regards Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
