wxWidgets 3.2.2.1: Does configure install wxWidgetsConfig.cmake?

[Joost Kraaijeveld]

Hi,

The subject says it all. Does configure install wxWidgetsConfig.cmake?

I have compiled and installed wxWidgets 3.2.2.1 using "configure --
prefix=/path/to/somewhere" and "make install". 

After this I want to use the wxWidgets-installation for a cmake-based
application with "CMAKE_PREFIX_PATH=/path/to/somewhere cmake ..". But
then cmake complains:

CMake Error at CMakeLists.txt:33 (find_package):
Could not find a package configuration file provided by "wxWidgets"
(requested version 3.2) with any of the following names:

wxWidgetsConfig.cmake
wxwidgets-config.cmake

Add the installation prefix of "wxWidgets" to CMAKE_PREFIX_PATH or
set
"wxWidgets_DIR" to a directory containing one of the above files. If
"wxWidgets" provides a separate development package or SDK, be sure
it has
been installed."

And indeed, there is no such file in the installation tree. But there
is one in the compilation tree though. It appears that "make install"
does not install it. Is that correct, i.e that does not happen? Should
it happen? Am I missing something?

TIA

--
Groeten,

Joost Kraaijeveld

[Vadim Zeitlin]

On Mon, 02 Oct 2023 20:06:51 +0200 Joost Kraaijeveld wrote:

JK> The subject says it all. Does configure install wxWidgetsConfig.cmake?

No, it doesn't.

JK> And indeed, there is no such file in the installation tree. But there
JK> is one in the compilation tree though. It appears that "make install"
JK> does not install it. Is that correct, i.e that does not happen? Should
JK> it happen? Am I missing something?

I don't know if it should happen. I guess we could install it because it
does no harm, so if you can make a (probably trivial, but it needs testing)
PR doing this, I'd merge it. But generally speaking I think the assumption
is that if you use CMake to build your application, you're also building
wxWidgets with it (because why not?) and then CMake would take care of
doing this.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
https://www.tt-solutions.com/

[Ian McInerney]

On Mon, Oct 2, 2023 at 7:34 PM Vadim Zeitlin <va...@wxwidgets.org> wrote:

On Mon, 02 Oct 2023 20:06:51 +0200 Joost Kraaijeveld wrote:

JK> The subject says it all. Does configure install  wxWidgetsConfig.cmake?

 No, it doesn't.

JK> And indeed, there is no such file in the installation tree. But there
JK> is one in the compilation tree though. It appears that "make install"
JK> does not install it. Is that correct, i.e that does not happen? Should
JK> it happen? Am I missing something?

 I don't know if it should happen. I guess we could install it because it
does no harm, so if you can make a (probably trivial, but it needs testing)
PR doing this, I'd merge it.

I don't think it is actually that simple. At least in my build, I don't see any wxWidgetsConfig.cmake generated into the build tree using the configure script. The only file with that in my entire wx folder is the one shipped in git inside build/cmake. That file needs to be configured by CMake before it could be used.

 

But generally speaking I think the assumption
is that if you use CMake to build your application, you're also building
wxWidgets with it (because why not?) and then CMake would take care of
doing this.

It actually is pretty common, at least on Linux. You generally don't build your own dependencies there, and at least Fedora (and I think Debian, but I can't check because apparently salsa.debian is down for me) build their system version using configure. So packages there rely on the upstream CMake find scripts to locate wx (hence why we in KiCad can't use CMake CONFIG mode for wx yet).

-Ian

 

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
              https://www.tt-solutions.com/

--

Ian McInerney
mcia...@gmail.com

No electrons were harmed in the making of this message

[Joost Kraaijeveld]

Just as Ian says. E.g. Debian (my distro) uses configure to build
wxWidgets as the system installed version. Now I cannot use the Debian
installed package with cmake for some applications I maintain. 

Of course I can solve this by maintaining 2 wxWidgets build-variants
with separate prefixes, one with configure and one with cmake, but just
one installed variant would be nice. If upstream would take care of the
possibility of using both build-system parallel I ebven would be happy
;-)

But then, I don't know whether this is difficult to do this with the
current configure-based build. Is it difficult?

--
Groeten,

Joost Kraaijeveld

[Joost Kraaijeveld]

BTW: comparing the installed versions of a configure-build and a cmake-
build one have a rather different set of installed files (besides
common files).

E.g. the cmake-version has Android-headers, dfb-headers, a different
set of generic headers (a super-set of the configure-set), gtk-private
headers, motif-headers etc.


--
Groeten,

Joost Kraaijeveld

[Vadim Zeitlin]

On Mon, 02 Oct 2023 22:04:46 +0200 Joost Kraaijeveld wrote:

JK> Just as Ian says. E.g. Debian (my distro) uses configure to build
JK> wxWidgets as the system installed version. Now I cannot use the Debian
JK> installed package with cmake for some applications I maintain. 

I don't know how do packagers handle this with the other libraries
supporting both autotools and CMake (we can't be the only ones, right?).

JK> But then, I don't know whether this is difficult to do this with the
JK> current configure-based build. Is it difficult?

I don't know, sorry. I guess the simplest way would be to use CMake to
just generate the required files and then install them?

On Mon, 02 Oct 2023 22:28:26 +0200 Joost Kraaijeveld wrote:

JK> BTW: comparing the installed versions of a configure-build and a cmake-
JK> build one have a rather different set of installed files (besides
JK> common files).
JK>
JK> E.g. the cmake-version has Android-headers, dfb-headers, a different
JK> set of generic headers (a super-set of the configure-set), gtk-private
JK> headers, motif-headers etc.

This looks like a bug in CMake install, it really shouldn't install all
these headers, especially the private ones.

[Maarten Bent]

There is https://github.com/wxWidgets/wxWidgets/issues/22714 that addresses the issue of different files being installed.
I haven't looked into it yet.

wxWidgetsConfig.cmake is not a stand-alone file. It relies on wxWidgetsTargets.cmake.
These target files are generated by CMake, and contain compile definitions, include directories, link dependencies and library paths and names for each library.

You can just generate them, add them to the repo, and include them in the installers.
Different configure options (like shared or static) will result in different library names.
And link dependencies (paths/names) could be different for different distros.
So you'll need some script that generates the config and target file(s), and fills them with the stuff from configure.
Which seems not at all trivial.

To solve your initial problem.
If wxWidgets is installed with configure, you can use find_package(wxWidgets) (https://cmake.org/cmake/help/latest/module/FindwxWidgets.html) (without CONFIG).
This use wx-config internally. Your configure install should have installed this wx-config.
So I think if /path/to/somewhere/bin is in your path, it should find and use that wx-config, and CMake will be able to find that wxWidgets installation.
Setting a WX_CONFIG env. var. is also possible.

Maarten

[Maarten Bent]

Confusing typo, it should have been: You CAN'T just generate them...