Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Problem compìling after r11701 (related to Direct2D)
gd_on:
--- Quote ---the build system and it updates them
--- End quote ---
Not totally sure : I have also correctly built (as Pecan) a new wxwidgets by only modifying \lib\gcc_dll\mswu\wx\setup.h. The one in include\wx\msw seems to be used in a totally fresh build when the lib's one does not still exists. To be totally sure, you can modify both. Nevertheless, take care if you cross build wxwidgets for several OS.
gd_on
killerbot:
I ran into the same problem when trying to build the nightly, win10 64 bit, gcc 8.1.0.
I will try the same thing that Pecan "trial and error-ed", but then there is the discussion that actually that file can exist in 2 locations, ...
Can this please be documented somewhere on the wiki, this is a real breaking change (one could even argue it should not be allowed in such a quick commit), which actually breaks for many people on how to build CB, if we do such things, it should be clearly documented, and the forum is not a good place, things are hard to find. It should be very clear in some section of the wiki.
And a "proven, fact supported solution" if possible, and not trial and errors got it working.
Who can help ?
When there is a good documentation, I will merge it into my nightly cookbook article on the wiki.
I will also mention it in the nightly "Important changes" since it means redistribution of a new wx dll-s.
And while we are rebuilding wx anyway, how about step up to 3.1.2, at the moment nightly is still at 3.1.1 ?
Miguel Gimenez:
I am using wx3.1.2 in 32 bits and it works OK, but you will get crashes with Code Completion if you don't backport New Pagodi's changes to wxPopupWindow in wx trunk to wx3.1.2
I published a patch with this backport (and the final files for easier use) in the forum, see http://forums.codeblocks.org/index.php/topic,22974.msg156992.html#msg156992
Regarding the wxWidgets configuration for Direct2D, if lib/gcc_dll/mswu/wx/setup.h exists then it is used for the compilation; if not, then include/wx/msw/setup.h is copied there when compilation starts. Cleaning the target does not delete the setup.h under lib, so any changes made to include/wx/msw/setup.h are ignored. EDIT: the safest way is deletion of lib/gcc_dll (or the 64 variant), edition of include/wx/msw/setup.h and making from scratch.
The only change required to setup.h is from
--- Code: ---#if defined(_MSC_VER) && _MSC_VER >= 1600
#define wxUSE_GRAPHICS_DIRECT2D wxUSE_GRAPHICS_CONTEXT
#else
#define wxUSE_GRAPHICS_DIRECT2D 0
#endif
--- End code ---
to
--- Code: ---#if defined(_MSC_VER) && _MSC_VER >= 1600
#define wxUSE_GRAPHICS_DIRECT2D wxUSE_GRAPHICS_CONTEXT
#else
#define wxUSE_GRAPHICS_DIRECT2D wxUSE_GRAPHICS_CONTEXT
#endif
--- End code ---
or
--- Code: ---#define wxUSE_GRAPHICS_DIRECT2D wxUSE_GRAPHICS_CONTEXT
--- End code ---
gd_on:
Hi,
--- Quote ---And while we are rebuilding wx anyway, how about step up to 3.1.2
--- End quote ---
To share my experience, I use myself wx 3.1.2 in 64 bits (since january). I have only added the "temporary" patch proposed by M. Gimenez in http://forums.codeblocks.org/index.php/topic,22974.msg156799.html#msg156799 and it works well. The advantage of this patch, is that it needs only a C::B code modification (though M. Gimenez declare it as non optimal)
I have not used the other patch (in http://forums.codeblocks.org/index.php/topic,22974.msg156992.html#msg156992) because it needs a wxwidgets 3.1.2 modification. And, if I understand well, these modifications have already been included in wxWidget 3.1.3 (by New Pagodi) ... but it's certainly too early to use this new future wx version !
gd_on
sodev:
There are as many setup.h files as variants you build plus one, in my case i have 9, 4 variants for GCC and 4 variants for MSVC. And those are not present before you actually build the variant at least one time. The wxWidgets documentation clearly tells you how to do the build, you modify the one in the include directory. This is a limitation of Windows where you don't have Autotools, no need to do that on Linux, there you setup the build using the configure script. Recent versions of wxWidgets can be build with CMake, didn't try this by myself, maybe that way is easier to use than the pregenerated Makefile's.
If you don't want to use a custom wxWidgets configuration (i think that is not a problem on Windows, there is usually no system wide library available unlike on Linux) the most proper way would be to figure out which MinGW versions do offer Direct2D support like it is done with the graphics context and propose a PR to wxWidgets so the default configuration will use Direct2D if available. But i don't know if this is possible reliable, AFAIK this is not really related to the compiler version but more to the WinAPI version, but this should also hold true for the graphics context.
About which revision to use, you are building nightly releases, why don't you use "nightly" wxWidgets revisions aka something recent from master? I am using master revisions of wxWidgets for many years now, only a few times i picked a "bad" revision that broke something, but way more often i just got new features and fixes plus i was up to date with breaking api changes. After all you are doing way less releases than wxWidgets, shouldn't be hard to synchronize your own release to one of wxWidgets if you insist on using a release version of it for a release ;)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version