>> A strategy I've seen used before is to arrange for all the build outputs
(libraries, executables) to end up in a directory structure that mimics the
installed layout. This can be helpful if the applications expect to find
things at some specific location relative to themselves at run time.
We'r
On Tue, Oct 9, 2018 at 8:18 AM Hendrik Greving <
hendrik.greving@gmail.com> wrote:
> Is there a good place to record the feature request (- if ack'd -)? gitlab
> issue?
> Thanks!
>
Gitlab is the place to record feature requests (and to check for existing
ones):
https://gitlab.kitware.com/cma
Is there a good place to record the feature request (- if ack'd -)? gitlab
issue?
Thanks!
On Thu, Oct 4, 2018 at 2:24 PM Hendrik Greving <
hendrik.greving@gmail.com> wrote:
> Hi, we would like to..
> (*) keep modularity and flexibility (i.e. avoid hard-coding relative
> paths) w/ binaries and
I think we ended up doing a lot of "if Qt version is X and System is Y) then
install Z" inside of our CMake codes. We abstracted out the Qt library names so
we just make lists of the libraries, plugins and system specific binaries that
are needed then the CMake code creates install rules to plac
Hi,
I'm currently trying to find a good approach to bundling Qt5 with my
application on Linux using CMake (and CPack to create tar.gz). It
appears this topic isn't covered very well - or I'm using the wrong
search keywords.
What I have right now is copying the different plugins that are needed
by
