wxWidgets port : Precompiled headers don't work - and setup.h confusion

[hajokirchhoff]

Describe the bug Predefined wxWidgets header wx/wxprec.h is broken with the vcpkg port. Compiling a large-ish application that #include wx/wxprec.h gives thousands (literally) of error messages complaining about undefined symbols that should be defined.

The port is broken for Windows and Visual Studio 2022.

Details vcpkg install wxwidgets builds and installs wxWidgets (3.2.4 in my case).

But #include <wx/wxprec.h>, which should include standard headers for wxWidgets, doesn't. This differs from the documented wxWidgets behaviour, so the wxWidgets vcpkg port works differently than the actual wxWidgets.

My application is built with Visual Studio 2022 under Windows. I am updating from a standard wxWidgets distribution to the vcpkg one. Now I get thousands (literally) of undefined symbols, because the standard wx header files (like wx/menu.h, wx/button.h etc...) are no longer included.

The problem is that the vcpkg portfile.cmake somehow generates a "setup.h" where the symbol __WX_SETUP_H__ is defined (two underlines), whereas the standard wxWidgets distribution defines _WX_SETUP_H_ (one underline). This difference causes wxprec.h to NOT define WX_PRECOMP and to NOT include the standard headers.

I've talked to @vadz from wxWidgets (see my ticket there: https://github.com/wxWidgets/wxWidgets/issues/24353) and we narrowed the problem down to the wxWidgets portfile.cmake.

Environment

• OS: Windows 11
• Compiler: Visual Studio 2022 17.9.0 Preview 3

To Reproduce Steps to reproduce the behavior:

1. ./vcpkg install wxWidgets
2. Compile code that uses #include wx/wxprec.h Get many error messages for undefined symbols such as wxMenu, wxMenuItem, wxStaticText etc... The appropriate header files should be included by wxprec.h but are not. Also, the define WX_PRECOMP is not set.

Expected behavior

ifndef WX_PRECOMP

error WX_PRECOMP is not set

endif

This #error should not trigger.

Additional context According to @vadz, the maintainer of wxWidgets, the setup.h file should not use __WX_SETUP_H__ (with two underlines).

Also there will be two different setup.h files installed. One at lib/msw*/wx/setup.h (which is correct), but another one with different contents to include/wx/msw/setup.h. The later should not be installed.

I'd love to help, but I am not sure who the original author of the portfile.cmake is and what their intended way of creating the setup.h file was.

More info can also be found over at https://github.com/wxWidgets/wxWidgets/issues/24353

[dg0yt]

To avoid misunderstandings: By "undefined symbols", do you refer to errors from the linker or from the compiler? Can you provide a minimal example? (FTR there is a test port which builds one of the examples coming with wxwidgets, to avoid regressions when updating the port. And I don't even have MSVC.)

[hajokirchhoff]

Here is a minimal sample:

#include <wx/wxprec.h>

wxList test;

This results in a

1>D:\Users\kir\repos\SignalSuite-vcpkg\consultants\iztWidgets\minimalsample.cpp(3,12): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

because wx/list.h should be included from wx/wxprec.h, but it isn't because the wx/setup.h defines __WX_SETUP_H__.

If you add the WX_PRECOMP define manually, the sample compiles fine:

#define WX_PRECOMP
#include <wx/wxprec.h>

wxList test;

But this isn't how it is supposed to work. For my non-vcpkg build under windows, WX_PRECOMP is defined automatically, because my setup.h isn't generated from https://github.com/wxWidgets/wxWidgets/blob/master/setup.h.in, but copied from https://github.com/wxWidgets/wxWidgets/blob/master/include/wx/msw/setup.h

[github-actions[bot]]

This is an automated message. Per our repo policy, stale issues get closed if there has been no activity in the past 28 days. The issue will be automatically closed in 14 days. If you wish to keep this issue open, please add a new comment.

[hajokirchhoff]

So, what are we going to do about this?

[dg0yt]

I guess we wait for upstream to add a resolution, now that they acknowledged it is an issue in their CMake. You could test a candidate patch.