Wt

Konstantin Podsvirov wrote:

CMake build system support two types of packages:

* Config-file Packages

* Find-module Packages

The project provides a Find-module package, but using the Config-file package is a more modern and preferred approach.

There is a pull request #116 at GitHub with implementation the feature.

Hey Konstantin,

I'm intrigued by your patches. I'm not familiar with these cmake features, which I'd like to take a look at before accepting the patch. If this is a functional replacement for FindWt.cmake (which is lacking many features), I'm very intererested in adding this to Wt.

Please ping me by email if you didn't get news in a week or so.

wim.

Hello Wim!

Note: to make exported package relocatable it is important set policy CMP0022 to NEW value. Because now the project does not use imported targets to indicate dependencies.

I am open to communication and I will be happy if we succeed in exporting the project in a new Config-file style.

The pull request #116 was forced updated.

Changes:

Use the NEW behavior for the policy CMP0022

to export relocatable Config-file package

The pull request #116 was forced updated.

Changes:

Use Boost IMPORTED targets if defined

We've had this on the wt4 branch for a while now, but one issue I notice is that it puts the full path to libhpdf in wt-config-wt.cmake instead of just libhpdf. Do you know how I could make it so that wt-config-wt.cmake specifies just libhpdf (or libhpdfd for debug builds) instead of the full path?

To create a relocatable package, we must use IMPORTED targets for all PUBLIC dependencies.

Unfortunately, as far as I know, the libHARU does not export IMPORTED targets. I hope this will be fixed in the future.

Quick solution: move the libHARU to PRIVATE dependencies. As before, WPdfImage and WPdfRenderer class users will have to find and link their targets with the libHARU library.

I found a way for it to just say libhpdf and libhdfd, by using add_library in WtFindHaru.cmake, but maybe the option to make libharu a private dependency could be a better solution. It's indeed not a public dependency unless WPdfImage or WPdfRenderer is used.

Another issue came up, actually. We make two builds on Windows: Debug (wt*d.lib) and MinSizeRel (wt*.lib). This causes the files wt-target-wt-debug.cmake and wt-target-wt-minsizerel.cmake to be generated. However, if someone uses the Wt package with a Release or RelWithDebInfo build, the debug libs end up being used. I would prefer CMake to choose the release libs in that case. Do you know of a good way to fix this? We don't want to do four builds.