Add option to build dependency as Shared Object (.so / .dll)

[carlos22]

This is especially useful for LGPL libraries which are used in non-LGPL/GPL compatible projects (including but not limited to commercial projects). Not sure if this is easy to implement. Any ideas?

[jrbarron]

@carlos22 I don't think that is something qpm could do automatically, but it is something we could maybe promote as a pattern that people should follow. The bare minimum required for a qpm package today is that it has a relatively simple .pri file. This file cannot be built by itself, but must be included by a .pro file in order for it to be a built. Today qpm is optimized for the case where the .pro that builds the dependencies is the same as the app, but there is no reason that you could not add another .pro file to your app that builds the shared library by including the .pri file of one (or more) dependencies. Your app could be structured like this:

-- src/
  |-- src.pro (TEMPLATE=subdirs)
  |-- app/
      |-- app.pro  (TEMPLATE=app)
  |-- libs/
     |-- libs.pro (TEMPLATE=subdirs)
     |-- package1/
         |-- package1.pro (TEMPLATE=lib, include(io_qpm_package1.pri))
     |-- package2/
         |-- package2.pro (TEMPLATE=lib, include(io_qpm_package2pri))
  |-- vendor/ (maintained by qpm)
     |-- io /
         |-- qpm /
             |-- package1 /
                 |-- io_qpm_package1.pri
             |-- package2 /
                 |-- io_qpm_package2.pri

Package authors could add a .pro themselves which simply includes the .pri file and specifies a shared library as the output. This is certainly a useful addition to a package and several packages have used this approach such that they can easily be included statically in an app or built as separate libraries/plugins. The bigger problem here might be managing include paths and exporting symbols. It's probably doable, but a documented example would probably help. In any case, I think this really has to be solved by the package authors since they are the ones who best know how to compile their package into a shared library. Would you agree or how do you see qpm solving this?

[Skycoder42]

Just leaving my comment here:
I thought about this idea, too. You are right, it's up to the developers to make packages "library-ready", but I think it would be useful to provide an "enviroment" to support this. You can't simply take any package build it as library, this will always be error prone.

The general Idea is: use specific macros etc, and your qpm package can be build as library by letting the user "change a switch" of qpm.

Just to give an idea, of what qpm could support (i.e. via an extended vendor.pri), to make this easier for developers and users:

• A switch for qmake. For example CONFIG += qpm_shared. Developers can use that very same variable to adjust their pri files, if necessary, and to correctly add the export/import macros
• Extend qpm to creat the library project for you and add references to app projects (as part of the vendor.pri). Something like qpm install --lib [package] for the library and qpm import [package] [local_path] for the app
• Add a flag to qpm.json to indicate if packages support this.
• The include problem can be fixed by using a qmake trick. I already did this as a package for a project that uses qpm as part of a static library (See qpm-include if interested)
• Provide project templates, guides, examples, etc. and "promote" hybrid packages (both normal and library) to the developers

The question of course is how far to take this, and how relevant it actually is. But it would defenitly be a nice little extra.

[carlos22]

I think what @Skycoder42 suggests sounds very reasonable. Currently I try to set up what @jrbarron suggested as solution to the problem. But better integration in qpm will help for greater use of the system - maybe also for some well-known libraries such as qwt or similar...