When building wxWidgets, the error below occurs if wxUSE_GEOMETRY is defined as 0.
4>...\wxWidgets\include\wx\event.h(2003,5): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
4> (compiling source file '../../src/common/dummy.cpp')
4>...\wxWidgets\include\wx\event.h(2003,26): error C2143: syntax error: missing ';' before '&'
4> (compiling source file '../../src/common/dummy.cpp')
Line 2003 is:
const wxPoint2DDouble& GetPosition() const { return m_pos; }
To repro on Windows with Visual Studio 2026:
Fresh clone
Set wxUSE_GEOMETRY and the dependent settings to 0:
--- a/include/wx/msw/setup.h
+++ b/include/wx/msw/setup.h
@@ -755,7 +755,7 @@
// Default is 1.
//
// Recommended setting: 1, setting it to 0 disables a lot of functionality.
-#define wxUSE_GRAPHICS_CONTEXT 1
+#define wxUSE_GRAPHICS_CONTEXT 0
// Enable wxGraphicsContext implementation using Cairo library.
//
@@ -816,7 +816,7 @@
// Default is 1
//
// Recommended setting: 1
-#define wxUSE_ACTIVITYINDICATOR 1 // wxActivityIndicator
+#define wxUSE_ACTIVITYINDICATOR 0 // wxActivityIndicator
#define wxUSE_ANIMATIONCTRL 1 // wxAnimationCtrl
#define wxUSE_BANNERWINDOW 1 // wxBannerWindow
#define wxUSE_BUTTON 1 // wxButton
@@ -1055,7 +1055,7 @@
#define wxUSE_DISPLAY 1
// Miscellaneous geometry code: needed for Canvas library
-#define wxUSE_GEOMETRY 1
+#define wxUSE_GEOMETRY 0
// Use wxImageList. This class is needed by wxNotebook, wxTreeCtrl and
// wxListCtrl.
@@ -1436,7 +1436,7 @@
// is used (although it will still save a few bytes probably).
//
// Recommended setting: 1.
-#define wxUSE_DC_TRANSFORM_MATRIX 1
+#define wxUSE_DC_TRANSFORM_MATRIX 0
// ----------------------------------------------------------------------------
// image format support
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
While patches/PRs fixing problems with disabling wxUSE_XXX would be welcome, we simply don't have resources to maintain all possible build configurations and my advice in general is to not do this, and it would be especially string in this case because disabling wxGC is just a bad idea.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Here are my patches:
Disabling geometry reduces our code size considerably on Windows. I consider this configuration feature quite valuable.
I found that disabling geometry is of no use on Linux or macOS. With GTK3 and macOS, graphics context is required. With GTK2, I could build the library but all the samples had link errors. However, these changes don't hurt anything for those platforms.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
While patches/PRs fixing problems with disabling
wxUSE_XXXwould be welcome, we simply don't have resources to maintain all possible build configurations
Has it been considered identifying and eliminating wxUSE_XXX flags that nobody really can nor wants to set to zero? wxUSE_BUTTON, wxUSE_CHECKBOX, ...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Here are my patches:
Thanks, but looking at it I see that it adds wxUSE_GEOMETRY guards around wxMultiTouchEvent::GetPosition() only, but then disables generating these events entirely, which doesn't seem right.
Perhaps we could define wxPoint2DDouble even when wxUSE_GEOMETRY==0? This one really shouldn't cost anything, it's a very simple class with only inline functions.
Also, it would be nice if you could please open PRs with your changes, as this would test them with all the CI jobs.
Disabling geometry reduces our code size considerably on Windows.
I would have never guessed... I wonder what exactly is bloating the code when it's on. There might be something wrong here.
I found that disabling geometry is of no use on Linux or macOS. With GTK3 and macOS, graphics context is required.
Yes, which is one of the reasons I think that disabling it under MSW is a bad idea.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
While patches/PRs fixing problems with disabling
wxUSE_XXXwould be welcome, we simply don't have resources to maintain all possible build configurations
Has it been considered identifying and eliminating
wxUSE_XXXflags that nobody really can nor wants to set to zero?wxUSE_BUTTON,wxUSE_CHECKBOX, ...
It's difficult to draw the line between things that nobody wants to disable and that somebody does want to disable. Until this issue got opened I would have been ready to bet that nobody disables wxUSE_GEOMETRY...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
While patches/PRs fixing problems with disabling
wxUSE_XXXwould be welcome, we simply don't have resources to maintain all possible build configurationsHas it been considered identifying and eliminating
wxUSE_XXXflags that nobody really can nor wants to set to zero?wxUSE_BUTTON,wxUSE_CHECKBOX, ...It's difficult to draw the line between things that nobody wants to disable and that somebody does want to disable. Until this issue got opened I would have been ready to bet that nobody disables
wxUSE_GEOMETRY...
Yes, drawing the line is difficult, but it boils down to: does it make sense to "support" disabling all and every component, whereas in reality a lot of wxUSE_XXX set to zero will result in compilation failure. As you wrote, there aren't (totally understandably) resources to maintain all possible configurations, but IMHO having all the #if wxUSE_BUTTON cluttering the code is pretending to maintain all possible configurations without doing it.
Also IMHO, a decision can be made that compiling wxWidgets without buttons/checkboxes/etc is not possible. If someone needs to disable something like that anyhow, they can maintain their own patch/fork – which is in practise the case right now too, as a lot of wxUSE_XXX set to zero do not compile.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
My suggestion to resolve the problem caused by disabling wxUSE_GEOMETRY is to eliminate wxUSE_GEOMETRY entirely.
My original assumption about code size reduction was wrong. There are three other options that depend on wxUSE_GEOMETRY. After some experimentation, I find that the code size reduction I observed is due to disabling those other three. Disabling wxUSE_GEOMETRY makes little to no difference. Only wxUSE_GEOMETRY is broken. Disabling the other three works as expected.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
OK, this makes much more sense.
wxUSE_GEOMETRY could indeed be removed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()