The 13 August 2022 build (12864) is out.

[killerbot]

building 3.1.7 :

patching:
* 2D patch (see below)
* (aui floating window) https://github.com/wxWidgets/wxWidgets/commit/0e57ed18518d0417759346541dd3c60e1f3e5e8e


2D patch:

Code Select Expand


include/wx/msw/setup.h

#if defined(_MSC_VER) && _MSC_VER >= 1600
    #define wxUSE_GRAPHICS_DIRECT2D wxUSE_GRAPHICS_CONTEXT
#else
    #define wxUSE_GRAPHICS_DIRECT2D 0
#endif

==> just 1 line
    #define wxUSE_GRAPHICS_DIRECT2D wxUSE_GRAPHICS_CONTEXT



and build instruction:

Code Select Expand


mingw32-make -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb CXXFLAGS+="-std=c++11"


[Miguel Gimenez]

If nobody has objections I will commit the MSW projects for wxWidgets 3.2 in 32 and 64 bits.

[gd_on]

If you are interested, here is a set of cbp files which are a compromise between standard wx31_64.cbps and Andrew Cotrell's versions. They need to set global variables and work for 32/64 bits, 3.0, 3.1, 3.2, and future wxwidgets versions. Just update need to be adapted (which is not the case for Andrew Cotrell versions because they are integrated in each cbp.)

[killerbot]

why do we even still but the effort in 32 bits, is there still some operating system supported by the vendors in 32 bit ?

[killerbot]

I support the idea we only have 1 cbp file which can deal somehow in a nice way with whatever wx version, instead of maintaining near duplicates.

[AndrewCot]

gd_on,
Thanks for taking the time to check out my project file changes and taking the time to make them better as per below.

Is it possible to get a 7z file with the directory structure preserved as then the project files will land in the correct directory if you unzip it in the correct directory. If you have a repo some where with the code I can grab the files from there to save time.

Is is also possible to get a copy of the config snippet for the global variables needed?
From my quick 5 minute look it seems that the $(CB_BUILD) has not been included. If this is the only change then it will help out a heck of allot and ensure that only one set of project files are
needed. The lack of using $(CB_BUILD) is a good one as it does bite when you move code and I have no problems with it's removal as it will lessen issues devs face (btw I keep getting issues with when I make copies of the soruce tree and forget to update it, so I am starting to <expletive removed> with it and have been thinking of reverting it for the last month). I will be incorporating the removal of the $(CB_BUILD) as I think it is the correct way to go.

[ollydbg]

Is is also possible to get a copy of the config snippet for the global variables needed?
From my quick 5 minute look it seems that the $(CB_BUILD) has not been included. If this is the only change then it will help out a heck of allot and ensure that only one set of project files are
needed. The lack of using $(CB_BUILD) is a good one as it does bite when you move code and I have no problems with it's removal as it will lessen issues devs face (btw I keep getting issues with when I make copies of the soruce tree and forget to update it, so I am starting to <expletive removed> with it and have been thinking of reverting it for the last month). I will be incorporating the removal of the $(CB_BUILD) as I think it is the correct way to go.

I just looked at the Cbps.7z file supplied by gd_on, it has some code snippet like:

Code Select Expand


<Target title="scintilla">
<Option output="devel$(#WXWIDGETS.WX_VERSION)_$(#CB_BUILD.OSBITS)/wxscintilla_cb" prefix_auto="1" extension_auto="1" />
<Option working_dir="" />
<Option object_output=".objs$(#WXWIDGETS.WX_VERSION)_$(#CB_BUILD.OSBITS)" />


So, I'm not sure how can you do that if you remove the "$(CB_BUILD)" (global variable) and use the existing "cb_release_type" variable?

[gd_on]

Here is an other packaging of my cbps for windows. I have also added in a pdf how env_vars are configured for me.
Nevetheless, my cbps still use some update*.bat which are not wxwidgets version independant. May be need still some work...

[MortenMacFly]

why do we even still but the effort in 32 bits, is there still some operating system supported by the vendors in 32 bit ?

From my point of view: Yes.

Reasons are:
1.) 32 bit IDE for 32 Bit compilers which are very well common in embedded environment (where you have the issue that a 32 bit gdb will not work in a 64 bit runtime)
2.) Schools and universities (which are main users of C::B) are still on 32 bit quite often
3.) We were nagged several times after we tried to released 64 bit only. We can try again, but I guess we will again be asked accordingly

[MortenMacFly]

Nevetheless, my cbps still use some update*.bat which are not wxwidgets version independant. May be need still some work...

I once played around with that and made the batch file accept a command line parameter that defines the wx version. This used to work. (I.e. when calling the batch file just call it with the value of the #wx global var.)

[AndrewCot]

I agree with Morten's reasons for keeping 32 bit support. I have been asked via PM's about about 4 or 5 times in the last year and Miguel built one a week or two ago. XAV build's nightly Windows 32 releases which end users can use without anyone knowing.

[Xaviou]

Hi.

why do we even still but the effort in 32 bits, is there still some operating system supported by the vendors in 32 bit ?

I'm still using a Win10-32bits at work on witch I have running version of Code::Blocks (it's why I regularly propose 32 bits versions of the nightly).

Regards.
Xav'

[ollydbg]

If nobody has objections I will commit the MSW projects for wxWidgets 3.2 in 32 and 64 bits.

I think we can commit the wx 3.2 cbps, and let people try the wx 3.2 builds.

The unified version cbps could be added later.

[Miguel Gimenez]

I agree with you, the unified version needs some testing/polishing and would delay usage of wx3.2.

I think it could be commited in parallel and become the only version by wx3.3.

[gd_on]

The unified version cbps could be added later.

the unified version needs some testing/polishing

Ok for me. Look also to Andrew's versions.