[wxwidgets] Update and fix

[dg0yt]

• What does your PR fix?

  Updates wxwidgets to 3.1.7.
  Fixes [wxwidgets] Build Failed with x64-mingw-dynamic on Windows 10 #25556 (insufficient install layout patch for 3.1.6).
  Fixes [wxWidgets] wxDEBUG_LEVEL should not be set to 0 #25437 (just reverting the patch using a default feature for debug support).

• Which triplets are supported/not supported? Have you updated the CI baseline?

  unchanged, no.
  Locally tested with vcpkg-ci-wxwidgets for x64-linux and x64-mingw-dynamic.

• Does your PR follow the maintainer guide?

  yes

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

  yes

[AenBleidd]

I don't agree with this PR. Please read my comment: #25437 (comment)

[dg0yt]

I don't agree with this PR. Please read my comment: #25437 (comment)

I assume you don't refer to the PR in general, but to the wxDEBUG_LEVEL aspect. For this aspect, my PR simply reverts the default (upstream) wxwidgets configuration as it is an immediate solution which unbreaks user projects. This is what you suggest:

it was decided that we should revert my change

This PR doesn't mean to provide a more advanced long-term solution "to control debug asserts in a more flexible way".
Which might be the outcome of #25551, if done right.

[AenBleidd]

@dg0yt, so maybe this PR and #25551 should not be merged separately then? Otherwise this PR will create regression if merged first.

[dg0yt]

Otherwise this PR will create regression if merged first.

I don't see how this PR creates a regression. It adds symbols, but it doesn't limit downstream usage. This is different from #25240 which removed things, causing regressions downstream. That's why this PR is a fix, even if it some might dislike the wxwidget's default debug level.

[AenBleidd]

@dg0yt, it will lead to this error again: BOINC/boinc#4806
When application requests complete removal of debug asserts, they will be still in wxwidgets and still enabled. Please see our discussion in the ticket I mentioned

[dg0yt]

it will lead to this error again: BOINC/boinc#4806 When application requests complete removal of debug asserts, they will be still in wxwidgets and still enabled. Please see our discussion in the ticket I mentioned

Possibly yes, but this may just indicate that you didn't find the right solution.
AFAIU boinc aready sets NDEBUG, but I don't see that it ensures calling wxDISABLE_DEBUG_SUPPORT for release builds.
(No search hits on GH for wxDISABLE_DEBUG_SUPPORT or wxIMPLEMENT_APP, but this is what the docs says:
https://docs.wxwidgets.org/trunk/overview_debugging.html#overview_debugging_config)

And include/wx/debug.h says:

0:  No assertion macros at all, this should only be used when optimizing
        for resource-constrained systems (typically embedded ones)

https://github.com/wxWidgets/wxWidgets/blob/7ad1bffa875f7a38db58b6069ea3ff0c49c211d2/include/wx/debug.h#L32-L33

[dg0yt]

For native mingw builds (on windows), I switched to the MSVC layout, so that the find module can operatore in win32 mode, not needing sh for wx-config. This reduces the amount of patching and wrapping.
Downside: there is no wx-config for mingw on windows. Mingw on linux is different.

[JackBoosY]

Ready for review?

[github-actions]

You have modified or added at least one vcpkg.json where you should check the license field.

If you feel able to do so, please consider adding a "license" field to the following files:

• scripts/test_ports/vcpkg-ci-wxwidgets/vcpkg.json

Valid values for the license field can be found in the documentation

[dg0yt]

Configuration without debug support now testable with:

./vcpkg install --overlay-ports scripts/test_ports wxwidgets[core] vcpkg-ci-wxwidgets

[talregev]

@JackBoosY Can you review it?

[marekr]

wx 3.2 is now available fyi, basically 3.1.7 with a minor bug fixes and documentation cleanup.

There's also now a cmake config file generated rather than needing findwxwidgets

[talregev]

I think we need to do 3.1.7 then go to 3.2.0.

[marekr]

I think we need to do 3.1.7 then go to 3.2.0.

I would argue it's not worth it. 3.2.0 is a patch release on 3.1.7 and just bug fixes. wx doesn't follow semver.

[talregev]

For 3.2.0 I think they will follow semver:

wxWidgets 3.2.0 is the first release in the 3.2 stable branch. This means that it will remain ABI-compatible with all the 3.2.x releases in the future, i.e. the applications using it will continue to work with the future releases in this series even without recompiling.

Also if it almost the same, then we can do 2 PRs. one for 3.1.7 then go to 3.2.0. Then users for vcpkg can choose versions in manifests mode. More versions to choose from, in a price of 2 commit and a couple of days delay.

[dg0yt]

This PR is 3.1.7, and it is ready. Merge as is unless there is a real issue, and do 3.2.0 after that.