Wx Setup.h Not Found

[Deandra Uleman]

Itis now 2016 and most of the above are 2012 so probably earlier versions of Code::Blocks or Widgets, but I found it was whenever I didn't have 'enable unicode' selected it gave the no Setup.h file error. With 'enable unicode' selected there is no problem.

Under some circumstances, while compiling on multiple cores, you mayreceive compilation error at the very beginning about missing setup.hfile. To overcome this issue, generate this file first withsetup_h tag at the end of build parameters:

In my case I have wxWidgets installed into C:\wxWidgets, so I had to add C:\wxWidgets\lib\gcc_x64_dll\mswud into search directories for compiler and C:\wxWidgets\lib\gcc_x64_dll for linker. This might also work for you.

I've just upgraded my machine to OpenSuSE Leap 15.5. In order to install a Python-based app named DisplayCAL, I need to setup the recent version of Python, wxWidgets, and the wxPython bindings. Python 3.11 is already on board:

Well yeah, I've found platform.h in /usr/include/wx-3.1/wx (and it does contain an include directive in line 159, so it must be the file I've been looking for), but I can't find no setup.h in this folder. Apparently it's not part of the wxWidgets-3_2-devel package.

After skimming through a Github issue, I found out that the necessary header files come with the tarball downloaded from PyPi, so I had to open the tarball and then copy the /ext/include/wx/setup_inc.h file into setup.h in the same folder.

Yes, from the documentation of wxPython I have read that it is mandatory to use 2.7 in order to compile. I do have both 3.10 and 2.7 in my system but I used 2.7.18 python in order to compile the package.

It seems that there is a symbolic link that points to the directory the script is trying to access but its the first time that I see symbolic links with an asterisk and I do not know what that is in Tumbleweed. Changing folder manually does not either work:

Yes I suppose wxWidgets is the package that did not compile correctly. Though I found it on YaST and installed it altogether. The result in this venv of python is the same. It always fails on [11/937].

Just for clarity, I stopped trying to build with python3 and went back to python 2.7 interpreter since the displayCAL program requested from the beginning of their documentation that it requires python 2.7. I used wxPython 4.1.0

This module finds if wxWidgets is installed and selects a defaultconfiguration to use. wxWidgets is a modular library. To specify themodules that you will use, you need to name them as components to thepackage:

There are two search branches: a windows style and a unix style. Forwindows, the following variables are searched for and set to defaultsin case of multiple choices. Change them if the defaults are notdesired (i.e., these are the only variables you should change toselect a configuration):

For unix style it uses the wx-config utility. You can select betweendebug/release, unicode/ansi, universal/non-universal, andstatic/shared in the QtDialog or ccmake interfaces by turning ON/OFFthe following variables:

There is also a wxWidgets_CONFIG_OPTIONS variable for all otheroptions that need to be passed to the wx-config utility. For example,to use the base toolkit found in the /usr/local path, set the variable(before calling the FIND_PACKAGE command) as such:

To save on compilation time, include only those header files relevant to the source file. If you are using precompiled headers, you should include the following section before any other includes:

The file "wx/wxprec.h" includes "wx/wx.h". Although this incantation may seem quirky, it is in fact the end result of a lot of experimentation, and several Windows compilers to use precompilation which is largely automatic for compilers with necessary support. Currently it is used for Visual C++ (including embedded Visual C++) and newer versions of GCC. Some compilers might need extra work from the application developer to set the build environment up as necessary for the support.

Shared libraries are handled with a more advanced form of linking, which makes the executable file smaller. They use the extension ".so" (Shared Object) under Linux and ".dll" (Dynamic Link Library) under Windows.

An executable file linked against a shared library contains only a small table of the functions it requires, instead of the complete machine code from the object files for the external functions. Before the executable file starts running, the machine code for the external functions is copied into memory from the shared library file on disk by the operating system - a process referred to as dynamic linking.

Dynamic linking makes executable files smaller and saves disk space, because one copy of a library can be shared between multiple programs. Most operating systems also provide a virtual memory mechanism which allows one copy of a shared library in physical memory to be used by all running programs, saving memory as well as disk space.

Some settings are a matter of taste, some help with platform-specific problems, and others can be set to minimize the size of the library. Please see the "setup.h" file and "install.txt" files for details on configuration.

When using the "configure" script to configure wxWidgets (on Unix and other platforms where configure is available), the corresponding "setup.h" files are generated automatically along with suitable makefiles.

On Microsoft Windows, wxWidgets has a different set of makefiles for each compiler, because each compiler's 'make' tool is slightly different. Popular Windows compilers that we cater for, and the corresponding makefile extensions, include: Microsoft Visual C++ (.vc) and MinGW/Cygwin (.gcc). Makefiles are provided for the wxWidgets library itself, samples, demos, and utilities.

We also provide project files for some compilers, such as Microsoft VC++. However, we recommend using makefiles to build the wxWidgets library itself, because makefiles can be more powerful and less manual intervention is required.

On Windows using MinGW/Cygwin, and on Unix and macOS, you invoke 'configure' (found in the top-level of the wxWidgets source hierarchy), from within a suitable empty directory for containing makefiles, object files and libraries.

All wxWidgets makefiles are generated using Bakefile wxWidgets also provides (in the "build/bakefiles/wxpresets" folder) the wxWidgets bakefile presets. These files allow you to create bakefiles for your own wxWidgets-based applications very easily.

In general, classes derived from wxWindow must dynamically allocated with new and deleted with delete. If you delete a window, all of its children and descendants will be automatically deleted, so you don't need to delete these descendants explicitly.

When deleting a frame or dialog, use Destroy rather than delete so that the wxWidgets delayed deletion can take effect. This waits until idle time (when all messages have been processed) to actually delete the window, to avoid problems associated with the GUI sending events to deleted windows.

In general wxWindow-derived objects should always be allocated on the heap as wxWidgets will destroy them itself. The only, but important, exception to this rule are the modal dialogs, i.e. wxDialog objects which are shown using wxDialog::ShowModal() method. They may be allocated on the stack and, indeed, usually are local variables to ensure that they are destroyed on scope exit as wxWidgets does not destroy them unlike with all the other windows. So while it is still possible to allocate modal dialogs on the heap, you should still destroy or delete them explicitly in this case instead of relying on wxWidgets doing it.

If you decide to allocate a C++ array of objects (such as wxBitmap) that may be cleaned up by wxWidgets, make sure you delete the array explicitly before wxWidgets has a chance to do so on exit, since calling delete on array members will cause memory problems.

Beware of deleting objects such as a wxPen or wxBitmap if they are still in use. Windows is particularly sensitive to this, so make sure you make calls like wxDC::SetPen(wxNullPen) or wxDC::SelectObject(wxNullBitmap) before deleting a drawing object that may be in use. Code that doesn't do this will probably work fine on some platforms, and then fail under Windows.

A problem which sometimes arises from writing multi-platform programs is that the basic C types are not defined the same on all platforms. This holds true for both the length in bits of the standard types (such as int and long) as well as their byte order, which might be little endian (typically on Intel computers) or big endian (typically on some Unix workstations). wxWidgets defines types and macros that make it easy to write architecture independent code. The types are:

where wxInt32 stands for a 32-bit signed integer type etc. You can also check which architecture the program is compiled on using the wxBYTE_ORDER define which is either wxBIG_ENDIAN or wxLITTLE_ENDIAN (in the future maybe wxPDP_ENDIAN as well).

One of the purposes of wxWidgets is to reduce the need for conditional compilation in source code, which can be messy and confusing to follow. However, sometimes it is necessary to incorporate platform-specific features (such as metafile use under MS Windows). The wxUSE Preprocessor Symbols symbols listed in the file setup.h may be used for this purpose, along with any user-supplied ones.

Some compilers, such as Microsoft C++, support precompiled headers. This can save a great deal of compiling time. The recommended approach is to precompile "wx.h", using this precompiled header for compiling both wxWidgets itself and any wxWidgets applications. For Windows compilers, two dummy source files are provided (one for normal applications and one for creating DLLs) to allow initial creation of the precompiled header.

However, there are several downsides to using precompiled headers. One is that to take advantage of the facility, you often need to include more header files than would normally be the case. This means that changing a header file will cause more recompilations (in the case of wxWidgets, everything needs to be recompiled since everything includes "wx.h").

3a8082e126