Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on August 13, 2022, 10:52:32 pm

Title: The 13 August 2022 build (12864) is out.
Post by: killerbot on August 13, 2022, 10:52:32 pm
We switched to wx 3.1.7 (with an extra patch applied on 13 August 2022) --> download the new wx dll's see link below

If you tested the 22 january nightly you may find your compiler executable has changed from gcc.exe to mingw32-gcc.exe and g++.exe to mingw32-g++.exe. Please correct this, you won't be asked again.

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works (http://forums.codeblocks.org/index.php/topic,3232.0.html).

A link to the unicode windows wxWidget dll(s) for Code::Blocks : https://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw31u_gcc_cb_wx317_2D_gcc810-mingw64-2.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls8.1.0.7z


The 13 August 2022 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2022/CB_20220813_rev12864_win64.7z
  - Linux :
   none

The current SDK version is : 2.20.0

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 13 August 2022 build (12864) is out.
Post by: killerbot on August 13, 2022, 10:53:42 pm
wx 3.1.7 WITH AN EXTA PATCH (aui floating window)
Title: Re: The 13 August 2022 build (12864) is out.
Post by: AndrewCot on August 14, 2022, 03:02:06 am
Thanks for the updated wx 3.1.7 DLL's as it fixed the moving/jumping debug dialogs I was seeing.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: killerbot on August 14, 2022, 04:49:30 pm
I would like to switch soon to wx 3.2 (again with the 2 patches we have applied to 3.1.7), does anyone has any objections, or reasons not to step-up (yet) ?
Title: Re: The 13 August 2022 build (12864) is out.
Post by: ollydbg on August 14, 2022, 04:56:19 pm
I would like to switch soon to wx 3.2 (again with the 2 patches we have applied to 3.1.7), does anyone has any objections, or reasons not to step-up (yet) ?

We do not have windows cbp files for wx3.2.
We have to tweak the cbp files for wx3.1.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: BlueHazzard on August 14, 2022, 06:20:02 pm
would love 3.2
We are still stuck on 3.0 on many linux distros...
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Miguel Gimenez on August 14, 2022, 07:24:08 pm
I have all MSW files for wxWidgets 3.2 in 32 bits, I can generate the 64 bits version and commit them all.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: stahta01 on August 14, 2022, 08:21:55 pm
I have all MSW files for wxWidgets 3.2 in 32 bits, I can generate the 64 bits version and commit them all.

I am having issues building wxSmith using wxWidgets 3.2.0 with STL configuration and MinGW64 GCC 12.1.0, did you have to patch wxSmith code?

Tim S.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Miguel Gimenez on August 14, 2022, 10:05:31 pm
My tests with STL build were made using wx3.1.5 and GCC 8.1, I have not tested STL recently. I can make some tests next tuesday.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: stahta01 on August 15, 2022, 12:36:14 am
My tests with STL build were made using wx3.1.5 and GCC 8.1, I have not tested STL recently. I can make some tests next tuesday.

Thank you if you do that; no hurry.
Code
H:\repos\git\devel\IDE_git_repos\codeblocks_sfmirror\src\plugins\contrib\wxSmith\wxwidgets\properties\wxsarraystringcheckproperty.cpp: In member function 'virtual bool wxsArrayStringCheckProperty::PropStreamWrite(wxsPropertyContainer*, wxsPropertyStream*)':
H:\repos\git\devel\IDE_git_repos\codeblocks_sfmirror\src\plugins\contrib\wxSmith\wxwidgets\properties\wxsarraystringcheckproperty.cpp:121:61: error: cannot bind non-const lvalue reference of type 'bool&' to an rvalue of type 'bool'
  121 |         Stream->PutBool(DataSubName + _T("_checked"),CHECK[i],false);

Tim S.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Miguel Gimenez on August 15, 2022, 11:11:40 am
Can you test this?
Code
        // Stream->PutBool(DataSubName + _T("_checked"),CHECK[i],false);
        bool Checked = CHECK[i];
        Stream->PutBool(DataSubName + _T("_checked"), Checked, false);
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Xaviou on August 15, 2022, 11:57:14 am
Hi.

OS X version of this rev can be downloaded from my Google Drive (https://drive.google.com/drive/folders/1-r9cbW1I8ZkaCt6iYDhcXH981n5FJTpV?usp=sharing).
There is only a macOS-11.6 version.
Note that it is not a notarized version of the application.

32 bits version for Windows can also be found in the same place (wx-3.1.7 with the aui patch).

Debian Buster and Bullseye (32 and 64 bits) can be installed from my repo (https://wxstuff.xaviou.fr/article/debian-repository.html).

Regards
Xav'
Title: Re: The 13 August 2022 build (12864) is out.
Post by: AndrewCot on August 15, 2022, 02:14:56 pm
Miguel,

Thanks for the Stream->PutBool post. I have incorporated this change and the code now builds using the MSYS2 wxWidgets 3.2 package. Finally got to the end and have been able to run C::B and load all of the plugins. I have not done any testing as it's time to go to bed.
I will check tomorrow if there are any other changes that are relevant as I have been concentrating on getting the build finished and then getting a run-able C::B and plugins.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Miguel Gimenez on August 15, 2022, 05:49:52 pm
Fixed in r12867 (https://sourceforge.net/p/codeblocks/code/12867/).
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Pecan on August 15, 2022, 06:27:47 pm
@ Killerbot
Could you tell us the parameters you use to compile wx3.1.7 for the nightly.

Or 3.2 when you're sucessful.
TIA
Title: Re: The 13 August 2022 build (12864) is out.
Post by: killerbot on August 16, 2022, 07:17:36 am
building 3.1.7 :

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


2D patch:
Code
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
mingw32-make -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb CXXFLAGS+="-std=c++11"
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Miguel Gimenez on August 16, 2022, 02:58:55 pm
If nobody has objections I will commit the MSW projects for wxWidgets 3.2 in 32 and 64 bits.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 16, 2022, 06:50:35 pm
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.)
Title: Re: The 13 August 2022 build (12864) is out.
Post by: killerbot on August 16, 2022, 08:36:05 pm
why do we even still but the effort in 32 bits, is there still some operating system supported by the vendors in 32 bit ?
Title: Re: The 13 August 2022 build (12864) is out.
Post by: killerbot on August 16, 2022, 08:37:00 pm
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.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: AndrewCot on August 17, 2022, 12:34:03 am
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.


Title: Re: The 13 August 2022 build (12864) is out.
Post by: ollydbg on August 17, 2022, 04:35:38 am

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
			<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?
Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 17, 2022, 10:58:06 am
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...
Title: Re: The 13 August 2022 build (12864) is out.
Post by: MortenMacFly on August 17, 2022, 11:08:31 am
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
Title: Re: The 13 August 2022 build (12864) is out.
Post by: MortenMacFly on August 17, 2022, 11:10:38 am
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.)
Title: Re: The 13 August 2022 build (12864) is out.
Post by: AndrewCot on August 17, 2022, 12:21:28 pm
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.

Title: Re: The 13 August 2022 build (12864) is out.
Post by: Xaviou on August 17, 2022, 12:35:27 pm
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'
Title: Re: The 13 August 2022 build (12864) is out.
Post by: ollydbg on August 17, 2022, 02:46:23 pm
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.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Miguel Gimenez on August 17, 2022, 03:00:21 pm
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.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 17, 2022, 03:40:30 pm
Quote
The unified version cbps could be added later.
Quote
the unified version needs some testing/polishing
Ok for me. Look also to Andrew's versions.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 17, 2022, 06:55:26 pm
Here is a new reworked version of my windows cbps : call to update.bat are now wxwidgets version independant, except for the main one, at the root.
good tests !
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Pecan on August 18, 2022, 10:56:07 pm
The Clangd_Client for this nightly can be downloaded at
https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/

Filename: ClangdClientForCBNightly_20220813_rev12864_win64.zip (Direct download link (https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/ClangdClientForCBNightly_20220813_rev12864_win64.zip/download))

Copy the included clangd_client.zip to  <YourCodeBlocksNightlyFolder>\share\CodeBlocks\clangd_client.zip
Do not unzip this file.

Copy the included clangd_client.dll to <YourCodeBlocksNightlyFolder>\share\CodeBlocks\plugins\clangd_client.dll

Restart your CodeBlocks Nightly.

Install instructions for LLVM/clangd are included within the downloaded .zip file.
Modify message
Title: Re: The 13 August 2022 build (12864) is out.
Post by: AndrewCot on August 19, 2022, 11:46:45 am
@gd_on (https://forums.codeblocks.org/index.php?action=profile;u=2422)I finally got a little time to check out your project files and the 10 or so I looked at were great. I will take a break from the stuff I have been working on and take the time to update my files with the changes.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 19, 2022, 12:49:30 pm
Thanks for testing.
A small tip : the base field of cb_build is not used here. You can simply put "" in this field. You can also put the path of src of Code::Blocks sources, which could be useful if you use the full paths to the sources in the cbps. But, as I use only relative path, it's not used.
gd_on
Title: Re: The 13 August 2022 build (12864) is out.
Post by: MaxGaspa on August 19, 2022, 03:50:35 pm
@Pecan

I installed the new version of your plugin using the latest nightly (Windows 7 pro SP1). I also installed the package

mingw-w64-x86_64-clang-tools-extra

in my MinGW64 installation and the related required dependencies (automatically installed  using pacman -S )

At the moment I have the version 14.0.6

Massimo@user-PC MINGW64 ~
$ clang -v
clang version 14.0.6
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/msys64/mingw64/bin

Massimo@user-PC MINGW64 ~
$ clangd -version
clangd version 14.0.6
Features: windows
Platform: x86_64-w64-windows-gnu

Massimo@user-PC MINGW64 ~
$

I configured the pluging and the clangd path was detected automatically. Now using any project I have (including the simplest one created with template "console application" I'm continuosly getting  two message windows attached.

The symbol browser is empty and the Codeblocks log  is

Opening C:\Development\Projects\aaaa\aaaa.cbp
Done.
ParseManager::CreateParser: Finish creating a new parser for project 'aaaa'
ProjectManager::SetProject took: 0.161 seconds.
ProjectManager::LoadProject took: 0.167 seconds.
LSP background parsing FINISHED for: (aaaa) C:\Development\Projects\aaaa\main.cpp (550 ms) (0 more)

I'm also attaching the simple project aaaa in the next  message

Is there any action I can do for helping?

Regards

Max









Title: Re: The 13 August 2022 build (12864) is out.
Post by: MaxGaspa on August 19, 2022, 03:51:32 pm
@pecan

Just attaching the aaaa project

Max
Title: Re: The 13 August 2022 build (12864) is out.
Post by: MaxGaspa on August 19, 2022, 08:35:42 pm
@pecan

I think I fixed the issue I had with your plugin. I discovered that I had a disk issue saving to the temporary folders. After a scandisk and deleting (forcing) the temp directory and using a new one the observed issue disappeared.  So it seems that the errors saving in the temp directory caused the issue.

Now your plugin is working (well !) and also the crashes i had in the past with a previous version are disappeared.

Max
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Pecan on August 19, 2022, 08:58:06 pm
@pecan

Just attaching the aaaa project

Max

Your aaaa project work perfectly on the latest CB nightly, here on my wx3.1.7 installation.

I suspect that the auto detect of clangd.exe is incorrect.
From the base of your msys64 install, using a command windows, issue the command "dir /s clangd*"

You'll probably find that you have two clangd.exe modules.
Like:
Code
F:\user\programs\msys64_13.0.1>dir /s clangd*
 Volume in drive F is HPHD2
 Volume Serial Number is 0873-0556

 Directory of F:\user\programs\msys64_13.0.1\clang64\bin

02/04/2022  11:50 AM        14,887,424 clangd.exe
               1 File(s)     14,887,424 bytes

 Directory of F:\user\programs\msys64_13.0.1\mingw64\bin

02/04/2022  11:49 AM        12,204,466 clangd.exe
               1 File(s)     12,204,466 bytes

Note that there's one clangd.exe in mingw64\bin
and another in clang64\bin.

Look into Setting/Editor/Clangd_client/ tab C/C++ Parser at the entry "Specify Clangd executable to use" and make sure it's set to your directory of mingw64/bin/clangd.exe

(https://forums.codeblocks.org/index.php?action=dlattach;topic=25068.0;attach=11236;image)
Title: Re: The 13 August 2022 build (12864) is out.
Post by: MaxGaspa on August 19, 2022, 09:33:57 pm

Your aaaa project work perfectly on the latest CB nightly, here on my wx3.1.7 installation.

I suspect that the auto detect of clangd.exe is incorrect.
From the base of your msys64 install, using a command windows, issue the command "dir /s clangd*"

You'll probably find that you have two clangd.exe modules.

I have just one clangd.exe in mingw64 but, as I reported the issue was related to some problems writing to the temp directory. I apologize for the time waste but I discovered the disk issue after  posting the messages (and I discovered it because another application was complaining...)

Now I'd like to know if I have discovered a bug or a feature.

Using a large project it is useful to reduce the symbol browser to show the current file symbols only. But switching from "Current Project's symbols" to "Current file's symbols" no changes in the symbol browser happens. See images. Moreover the namespace is not expanded regardless the setting "Automatically expand namespaces".

Great work anyway !!!!

 
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Pecan on August 20, 2022, 07:04:28 pm
Partial quote
Now I'd like to know if I have discovered a bug or a feature.

Using a large project it is useful to reduce the symbol browser to show the current file symbols only. But switching from "Current Project's symbols" to "Current file's symbols" no changes in the symbol browser happens. See images. Moreover the namespace is not expanded regardless the setting "Automatically expand namespaces".

@MaxGaspa, thanks for testing and thanks for the input.

Unfortunately I've not had the time to pay much attention to the Symbol browser. I hope to do so some time in the future when clangd_client core code runs sucessfully for one month without need of serious fixing.

I've entered the missing features (as you've noted) into the clang_client ticket system so they won't get lost.

Does it help to view/expand the namespace name instead (see attatched image) ?
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 20, 2022, 09:55:16 pm
@gd_on:
If I read what you downloaded correctly, you have it setup for a 32-bit build using a particular 32-bit compiler.  Have you given any thought to being able to use any 32-bit/64-bit compiler?

Regards
Title: Re: The 13 August 2022 build (12864) is out.
Post by: stahta01 on August 21, 2022, 08:27:17 am
@gd_on:
If I read what you downloaded correctly, you have it setup for a 32-bit build using a particular 32-bit compiler.  Have you given any thought to being able to use any 32-bit/64-bit compiler?

Regards

Do you have any reason to believe what you posted?
The only 32 I found was for wxWidgets 3.2 the stuff I found used 64 for osbits.

So, what are you talking about if it is not "Cbps_3.7z" in https://forums.codeblocks.org/index.php/topic,25068.msg170872.html#msg170872 (https://forums.codeblocks.org/index.php/topic,25068.msg170872.html#msg170872) ?

Tim S.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 21, 2022, 10:01:26 am
my cbp are not so different than standard ones. This work, based on Andrew Cotrell's one, try to avoid some hard coding settings.
Main differences are in folder name build which are initialised with global variables instead of beeing hard coded.
May be the major diference for 32 bit build is : for example with wxWidgets 3.1, the forder name with standard build are .objs31 and devel31, and with my cbp they are .objs31_32 and devel31_32, following the same logic than for 64 build names.
Also, compilation option -m32 or -m64 is built according to the global variable cb_build.osbits. The same for the name of the used wxwidgets libraries.
The compiler is simply gcc (as in standard build). So it's the 1st compiler found in your system path : it may be 32 or 64 bits, depending of your path settings order.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 21, 2022, 09:26:58 pm
@gd_on:
Currently building a 64-bit version of SVN 12877, using re-named and  up-dated versions of Codeblocks_wx31_64.cbp and ContribPlugins_wx31_64.workspace. The plugins' cbp and update*.bat (if provided) files were also re-named and up-dated.

However, prior to using my cbp and workspace files, I placed the files you provided in cbps_3.7z into the proper directories and updating my global variables. Attempting to use your Codeblocks_Windows.cbp and codenlocks_Windows.workspace resulted in errors preventing the build to start. Couldn't seem to find the compiler.  No changes made to oolchain.

Any idea what's cauings this behavior?

Regards
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 21, 2022, 10:09:36 pm
@gd_on:
The code at the start of Codeblocks_Windows.cbp and Codeblocks_wx32_64.cbp
Code
?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
<FileVersion major="1" minor="6" />
<Project>
<Option title="Code::Blocks Windows" />
<Option default_target="src" />
<Option compiler="gcc" />
<MakeCommands>
<Build command="" />
<CompileFile command="" />
<Clean command="" />
<DistClean command="" />
<AskRebuildNeeded command="" />
<SilentBuild command=" &gt; $(CMD_NULL)" />
</MakeCommands>
<Build>

=======================================================================

?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
<FileVersion major="1" minor="6" />
<Project>
<Option title="Code::Blocks wx3.2.x (64 bit)" />
<Option default_target="src" />
<Option compiler="gnugcc_x64_compiler" />
<Build>


The Make commands in your .cbp Throw me. Are they necessary?

Regards
Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 22, 2022, 10:18:56 am
Those lines :
Quote
      <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 :
Quote
      <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.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 22, 2022, 09:42:26 pm
@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
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 23, 2022, 01:05:07 am
@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
Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 23, 2022, 11:01:29 am
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 :
Quote
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.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 23, 2022, 08:40:39 pm
@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
Title: Re: The 13 August 2022 build (12864) is out.
Post by: stahta01 on August 24, 2022, 01:10:47 am
@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.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: tomay3000 on August 24, 2022, 02:15:42 am
You may also consider the MinGW Builds update: https://github.com/niXman/mingw-builds-binaries/releases/latest (https://github.com/niXman/mingw-builds-binaries/releases/latest)
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 24, 2022, 02:36:07 am
@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
Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 24, 2022, 10:15:39 am
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.


Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 24, 2022, 11:17:45 am
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
Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 24, 2022, 04:04:55 pm
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 (https://sourceforge.net/p/codeblocks/tickets/1300/).

gd_on
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 24, 2022, 09:00:57 pm
@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
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 24, 2022, 10:32:46 pm
@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
Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 24, 2022, 11:28:42 pm
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.

Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 25, 2022, 12:33:22 am
I've replaced any versions of World.cbp that I may have modified.

Quote
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.






Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 25, 2022, 09:38:48 am
Quote
Is cb_release_type with base of -g equivalent to cb_build  with cflags of -O2 ?
No. cb_release_type with base of -g is equivalent to cb_build with cflags of -g. For me cb_release-type has exactly the same meaning and usage than cb_build.cflags.
I have done this because it's not a good practice to have two different variables with the same contents and are supposed to do the same thing. So, as made by Andrew Cottrel in his own cbps, I have chosen to use cb_build.cflags and to replace all cb_release_type which were still present in some cbps.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 25, 2022, 06:50:53 pm
@gd_on:
I didn't think so. However, your latest World.cbp has several occurrences of the variable cb_release_type being used. That is contrary to your statements that you no longer use that variable. My cb_release_type is -g. The cb_build.cflags variable is -O2 per your instructions. I doubt that is what causes my build failures.

However, with over 4350+ statements in World.cbp, there could possibly be other things that were overlooked.

Regards
Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 25, 2022, 07:16:33 pm
You are right, but there was only one cb_release_type, in codeblocks_windows.cbp and unfortunately at a global level, so used at each compilation!
Here again a corrected version.

PS: to be sure that nobody will use old versions, I have deleted all other Cbps_*.7z in previous post.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 25, 2022, 08:57:26 pm
@gd_on:
There are 4361 lines of code in 32_64.cbp and 4356 lines of code in World.cbp. You removed the following lines of code from 32_64.cbp:
Code
                        <Environment>
<Variable name="WX_CFG" value="64" />
<Variable name="WX_SUFFIX" value="u" />
<Variable name="WX_VERSION" value="32" />
</Environment>
, but never replaced them with the global variables you created for wxwidgets. I suspect this is causing the failures.

I used WinMerge to compare the two programs.

Regards
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 25, 2022, 09:22:47 pm
A couple tools you might find useful !

WinMerge is an open sorce application from: www.winmaege.org

XML Editor is a free application from: https://xml-copy-editor.sourceforge.io/

Regards
Title: Re: The 13 August 2022 build (12864) is out.
Post by: stahta01 on August 25, 2022, 09:30:17 pm
A couple tools you might find useful !

WinMerge is an open sorce application from: www.winmaege.org

XML Editor is a free application from: https://xml-copy-editor.sourceforge.io/

Regards

Please DO NOT POST FAKE LINKS!
https://winmerge.org/ (https://winmerge.org/)

Tim S.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 25, 2022, 10:22:56 pm
@stahta01:
Thanks Tim for correcting the link. It wasn't done intentionally.  It worked in my browser..

Regards
Title: Re: The 13 August 2022 build (12864) is out.
Post by: Frank_CB on August 25, 2022, 10:41:16 pm
@gd_on:
I may have been pre-mature in claiming you no longer used wx_version; wx_suffix or wx_cfg after you removed tham from Worlds.cbp. Further investigation found you had incorporated them into other statements as global variables.

Sorry !

Regards
Title: Re: The 13 August 2022 build (12864) is out.
Post by: gd_on on August 26, 2022, 12:22:31 am
This is exactly one of tje main purposes why I have created these global variables : avoid local copies in many different cbp.
And don't worry, I know wincmp, winmerge and even some other tools...
Title: Re: The 13 August 2022 build (12864) is out.
Post by: ThierryD on August 29, 2022, 04:10:01 pm
Hi,
Maybe bug in last version nightly build v12864.
I use many useful environment variables to manager versions of Visual Studio 2022 Community, Kits Window and CLANG on Windows 11 (last versions).
Examples in CB configuration of differents compilers with CLANG integrated with VS 2002 ->
Search directories :
   a) compiler :          C:\Program Files (x86)\LLVM\lib\clang\%CLANG_VERSION%\include                       puis
                     C:\Program Files (X86)\Windows Kits\%KIT_WIN_VERSION%\include\%KIT_WIN_NUM%\shared    puis
                     C:\Program Files (X86)\Windows Kits\%KIT_WIN_VERSION%\include\%KIT_WIN_NUM%\ucrt      puis
                     C:\Program Files (X86)\Windows Kits\%KIT_WIN_VERSION%\include\%KIT_WIN_NUM%\um        puis
                     C:\Program Files\Microsoft Visual Studio\%VS_VERSION%\Community\VC\Tools\MSVC\%VS_NUM%\include
   b) linker :          C:\Program Files (x86)\LLVM\lib\clang\%CLANG_VERSION%\lib\windows                    puis
                     C:\Program Files (X86)\Windows Kits\%KIT_WIN_VERSION%\lib\%KIT_WIN_NUM%\um\x86        puis
                     C:\Program Files (x86)\Microsoft Visual Studio\%VS_VERSION%\Community\VC\Tools\MSVC\%VS_NUM%\lib\x86
                     C:\Program Files (X86)\Windows Kits\%KIT_WIN_VERSION%\lib\%KIT_WIN_NUM%\ucrt\x86     puis
                     C:\Program Files\Microsoft Visual Studio\%VS_VERSION%\Community\VC\Tools\MSVC\%VS_NUM%\lib\x86\store
   a) resource compiler :    C:\Program Files (x86)\LLVM\lib\clang\%CLANG_VERSION%\include                       puis
                     C:\Program Files (X86)\Windows Kits\%KIT_WIN_VERSION%\include\%KIT_WIN_NUM%\shared    puis
                     C:\Program Files (X86)\Windows Kits\%KIT_WIN_VERSION%\include\%KIT_WIN_NUM%\ucrt      puis
                     C:\Program Files (X86)\Windows Kits\%KIT_WIN_VERSION%\include\%KIT_WIN_NUM%\um        puis
                     C:\Program Files\Microsoft Visual Studio\%VS_VERSION%\Community\VC\Tools\MSVC\%VS_NUM%\include

With CB last nightly, translation of these environnement variables don't work correctly :
Cleaned "dlg_two - Debug CLANG MSX32"

-------------- Build: Debug CLANG MSX32 in dlg_two (compiler: LLVM Clang Compiler X32)---------------

Running target pre-build steps
rc.exe -I"C:\LLVM\lib\clang\14.0.6\include" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\shared" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\ucrt" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\um" -I"C:\Program Files (x86)\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.30.30705\include" /fo "objCLANGX32\Debug\dlg_two.res" dlg_two.rc
Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation.  All rights reserved.
dlg_two.rc(11) : fatal error RC1015: cannot open include file 'windows.h'.

Value of defined variables on my system :
         KIT_WIN_VERSION        10.0.22621.0
         KIT_WIN_NUM              10
         VS_VERSION        10.0.22621.0
         VS_NUM               10
         
         
Title: Re: The 13 August 2022 build (12864) is out.
Post by: ThierryD on August 29, 2022, 04:10:55 pm
Many thank's.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: ThierryD on August 29, 2022, 04:45:25 pm
Hi (ter),
Apology for error in last typo :
        VS_VERSION       2022
        VS_NUM              14.33.31629

Sorry, but diagnostic is the same.

Many thanks. 
Title: Conclusion : not a bug, but only my error ...
Post by: ThierryD on September 03, 2022, 03:41:57 pm
Hi,
Ma last alert about possibly bug with last version NB of CB is an error ... of mine ...
I haven't changed the pre-build procedure to adapt this with good envoronment variables, but coding with "hard path" to "include" directories.
After upgrade with last version of VS2002 and kit Windows (and purge precedent version), nothing work, it's clear !!!
The problem is placed beetween keybord and screen ... and it's me ..
Forgive me, you can close this alert.

Thank's.   
Title: Re: The 13 August 2022 build (12864) is out.
Post by: AndrewCot on September 14, 2022, 02:26:56 am
I would like to switch soon to wx 3.2 (again with the 2 patches we have applied to 3.1.7), does anyone has any objections, or reasons not to step-up (yet) ?

I think wx 3.2.1 is good to switch to now as it does not require any patches and is being used by allot of the C::B devs now.
Title: Re: The 13 August 2022 build (12864) is out.
Post by: baloghi on September 15, 2022, 08:48:11 pm
I am not sure is there database explorer plugin support in this version?

Thank you for your answer.