The 13 August 2022 build (12864) is out.

[gd_on]

Those lines :

      <MakeCommands>
         <Build command="" />
         <CompileFile command="" />
         <Clean command="" />
         <DistClean command="" />
         <AskRebuildNeeded command="" />
         <SilentBuild command=" &gt; $(CMD_NULL)" />
      </MakeCommands>

are not in my codeblocks_windows.cbp. Of course, they are not necessary.

More, the line :

      <Option compiler="gnugcc_x64_compiler" />

is not in the standard CodeBlocks_wx32_64.cbp (it's simpy gcc, as in mine).

So, you have modified the provided cbp (automatically, intentionally or not, ... I don't know).

I think that <option compiler="gcc" /> line refer to the default compiler in C::B. So, if it is correctly set for 64 bits set (in my case gcc, g++ in C:\msys64\mingw64\bin) (or 32 bit set for 32 bit build), cbp should work as they are, without modifying them.

Nevertheless, I have found a small problem in my previous cbp : for exchndl, the path win64 was still hard coded. Here is a modified version which should be better for 32 bits only build.

[Frank_CB]

@gd_on:
My heartfelt apologies! I never intended to infer that your Codeblocks_Windows.cbp file had any unnecessary code in it. I checked what you downloaded (Cbps_3.7z) and found no extra code in Codeblocks_Windows.cbp. I certainly didn't add it to your Codeblocks_Windows.cbp before using it. The only thing I changed was the compiler which I have always used for 64-bit builds. I don't have a "gcc" selection for a compiler. I suppose i could copy gnu/gcc and name it gcc (a late thought).

The Codeblocks_wx32_64.cbp was copied from my Codeblocks_wx31_64.cbp  It used the compiler I have always used 64-bit builds. That compiler was copied from the gnu/gcc  compiler and had it's toolchain correctly updated (C:\Mingw64).

When I go through building a 64-bit build the first time a new version of wxWidgets comes out I have to change the compiler and set wx-cfg to 64 for the core. Then for the ContribPlugins I need to step through each plugin or contributed plugin and change the compiler and wx_cfg.  I also have to re-arrange the search directories order to place the directory containing setup.h first. A time consuming project. Subsequent builds, as long as wxWidgets version doesn't change, are a breeze. There might be a more efficient way to do it, but since it's a hobby, i'll continue.

Regards

[Frank_CB]

@gd_on:
Am attempting to use Codeblocks_Windows.cbp. Any idea why these two include directories ( -I.objs32_64\include and -I. ) are showing up in the build log, but aren't defined anywhere else, that I'm aware of? The 64-bit build runs fine until it fails in scintella because it couldn't find wxprec.h. The include directory statement that defines where setup.h is now in position 3 instead of position 1 (wxWidgets stipulation for 64-bit builds).

Have created a compiier that i'm calling "GCC" and set it up to be 64-bit.

Regards

[gd_on]

As far as I understand, the problems you describe should also happen with standard *32_64.cbp versions. If you compare line by line *32_64.cbp versions and *windows.cbp versions you can see that only names are buillt with global variables instead of hardcoding 32, 64 and 32_64.
So, -I.objs32_64\include and -I. are also used by standard 32_64 (and even 31_64) versions. In particular, .objs32_64\include is a directory where precompiled headers *.gch are stored.
The  order of lines are not changed, as far as I remember.
For wxprec.h, I have no explanations. Your statement :

The include directory statement that defines where setup.h is now in position 3 instead of position 1

is not precise. Where did you see that ?
I have not created a specific "GCC" but I simply use the standard "GNU GCC Compiler" as my default compiler, but with fields set with path and names of my 64 bits used compilers.

[Frank_CB]

@gd_on:
Your correct, those two extra includes are in both *wx32_64.cbp and *World.cbp. That definitely throws a monkey wrench into my practice, when creating 64-bit builds, of re-arranging the order of include directories for the compilers to insure that the directory that contains setup.h is first. I've been doing that for at least 10 years. I cannnot recall where I read that requirement? It works for *wx32_64.cbp, but not for *World.cbp. I'm at a loss as to what is causing that. i just hope that the other four individuals that downloaded your cbps_3.7p are having better success.

Have you successfully built 32-bit and 64-bit versions of Codeblocks from your modified cbps? I assume that you have.

I am attaching a zipped file that contains build logs and build messages for both *wx32_64.cbp and *World.cbp.

Regards

[stahta01]

@gd_on:
Your correct, those two extra includes are in both *wx32_64.cbp and *World.cbp. That definitely throws a monkey wrench into my practice, when creating 64-bit builds, of re-arranging the order of include directories for the compilers to insure that the directory that contains setup.h is first. I've been doing that for at least 10 years. I cannnot recall where I read that requirement? It works for *wx32_64.cbp, but not for *World.cbp. I'm at a loss as to what is causing that. i just hope that the other four individuals that downloaded your cbps_3.7p are having better success.

Have you successfully built 32-bit and 64-bit versions of Codeblocks from your modified cbps? I assume that you have.

I am attaching a zipped file that contains build logs and build messages for both *wx32_64.cbp and *World.cbp.

Regards

Having the include for setup.h before the other wxWidgets library include works best if you build the PCH for wxWidgets and install it in the same folder that holds setup.h. I have not done that for many years; the standard directions do not build the wxWidgets PCH file and I doubt the CB projects truly use the wxWidgets correctly.

Tim S.

[tomay3000]

You may also consider the MinGW Builds update: https://github.com/niXman/mingw-builds-binaries/releases/latest

[Frank_CB]

@gd_on:
There's a spreadsheet displayed as a pdf file attached that shows the parameters for g++ compiling LexerAdA.o.  Only one parameter is different between Codeblocks_wx32_64.cbp and Codeblocks_World.cbp. 'O2' is not equivalent to 'std=gnu++11' as far as I know. O2 was shown as part of a global variable displayed in the pdf file you provided in Cbps_3.7p. By adding it to my global variables, I probably created my own problems.

@stahta01:
Thanks Tim

Regards

[gd_on]

May be, you have not strictly followed indications given in my Env_vars.pdf. It seems that your global variables are not set correctly, especially cb_build.
To be compatible with standard 32_64 cbp, you must set cb_build.cpp_std to gnu++11 (I use gnu++20 but gnu++11 is OK) and cb_build.cflags to -O2. Don't confuse them. I see in your build files that -O2 is sometimes missing and gnu++11 probably misplaced.
In my cbp, I don't use the content of cb_release_type : it is replaced by cb_build.cflags with the same content. But I keep cb_release_type as it is in my global variables, to be compatible with standard cbps.

[gd_on]

Oups ! Sorry. I have just found than in one of my cbps (at least, but the main one: Codeblocks_Windows.cbp) there was a confusion between cb_build.cpp_std and cb_build.cflags.
I'll correct that.
Sorry again

[gd_on]

OK. Problem corrected (I hope so !). See the new attachment. Nevertheless, I'm not sure it solves problems met by Frank_CB, which comes from something else I think : compiler, environment, wxwidgets build, ... ?

Build logs between standard w32_64 workspaces and mine are compatibles.

Dooing this, I have remarked that there is a small difference in how are used and interpreted local and global variables, at least for wx_cfg in cbp files which by default is an empty string. Does not seem to cause problems in Windows but a little bit annoying. I have filled a ticket for that #1300.

gd_on

[Frank_CB]

@gd_on:
As you'll notice in the following build-log snippet std=gnu++11 has returned, but the cflag -O2 is missing. The variable cpp_std is called std. The 64-bit build failed earlier, I had updated my env-vars per your last instructions in cbps_5.7z I have no idea if a missing cflag variable and/or a misspelled vsriable could cause the failures.

Code

g++.exe -Wall -std=gnu++11 -m64 -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DwxUSE_UNICODE -D_WIN64 -D__WX__ -DWINVER=0x0501 -DLINK_LEXERS -DSCI_LEXER -DWXMAKINGDLL_SCI -iquote.objs32_64\include -I.objs32_64\include -I. -IC;\wxWidgets-3.2.0\include -IC;\wxWidgets-3.2.0\lib\gcc_dll64\mswu -Isdk\wxscintilla\include -Iinclude\tinyxml -Isdk\wxscintilla\src\scintilla\include -Isdk\wxscintilla\src\scintilla\src -Isdk\wxscintilla\src\scintilla\lexlib -c C:\projects\12877\src\sdk\wxscintilla\src\scintilla\lexers\LexAsn1.cxx -o .objs32_64\sdk\wxscintilla\src\scintilla\lexers\LexAsn1.o
C:\projects\12877\src\sdk\wxscintilla\src\PlatWX.cpp:8:10: fatal error: wx/wxprec.h: No such file or directory
 #include "wx/wxprec.h"

The attached png file shows cb_build after your instructions in cbps_3.7z. I couldn't have followed your instructions more explicitly.

Ihank you for taking the time to reply to alll my comments addressed to you. Maybe someone else can figure out what is causing the problems when I try to build 64-bit builds using your cbps. I'll just wait until your cbps show up in source.  Until then, I have my own Codeblocks_wx32_64.cbp and ContribPlugins_wx32_64.workplace files that work.

Again, Thank you !

Regards

[Frank_CB]

@gd_on:
wx_cfg is used by Codeblocks to specify which wxWidgets library to use. I have always set it to 64. Leaving it blank infers a 32-bit wxWidgets library. You may want to question the ticket you submitted?

Regards

[gd_on]

Why not, but in all wx32_64.cbp, the wx_cfg value is empty or set as "".

Code

<Variable name="WX_CFG" value="" />

And I don't understand why -O2 is missing on the command line and why it does not work for you (wxprec.h not found). If -O2 is found for cpp files with wx32_64 cbp, it should also be found in _windows.cbp, except if you have modified something in my cbp. As I told, I use no more cb_release_type but cb_build.cflags (with the same -O2 value) to be homogeneous in all the cbps.

[Frank_CB]

I've replaced any versions of World.cbp that I may have modified.

modified something in my cbp. As I told, I use no more cb_release_type but cb_build.cflags (with the same -O2 value) to be homogeneous in all the cbps.

Is cb_release_type with base of -g equivalent to cb_build  with cflags of -O2 ?

I have always modified wx3x_64.cbp by setting wx_cfg to 64. It had been blank.