Recent Posts

Pages: 1 2 [3] 4 5 6 7 8 ... 10
Development / Re: Remove coders query from plugins
« Last post by AndrewCot on Yesterday at 02:02:37 am »
Looks like removing cb_koders was proposed a while ago. The changes along with a bunch of other ones can be seen in the following PR:
Development / Re: Leap-15.3 : wx-315 for cb12673
« Last post by LETARTARE on Yesterday at 01:40:41 am »
1- I only use the construction provided,
2- I'm dizzy, I'm using 'KdeSvn' since recently and I forgot to validate the new 'Project/Workspace' files ...
3- 'Leap-15.3' allows to have: 'wx-3.0.5' AND 'wx-3.1.5', but the development packages are exclusive from each other, so I had some difficulties to use 'update-alternatives' ... and then I choose one or the other : currently I use 'wx-3.1.5',
4- I let the developer adapt his project,
5- it's by reading 'Unbunto.patch' by 'Michel Gimenez' that I tried to switch to 'wx-3.1.5', to not modify his work, it is long enough and not very gratifying !

I attach a version that I hope corrected ...

I leave you because the tennis matches start in your area ...
Nightly builds / Re: The 22 January 2022 build (12672) is out.
« Last post by AndrewCot on Yesterday at 12:52:18 am »
I agree with Miguel for what it's worth.
Development / Re: Leap-15.3 : wx-315 for cb12673
« Last post by AndrewCot on Yesterday at 12:02:19 am »
Thanks for the work. I can use this in a few weeks to cross reference the changes I have been working on for the current Linux workspace/project build as it has some missing plugins at the high level.

Some feedback:
1) There are three ways to build on Linux as per the following list. You have done one, but the other two is the way the nightly and release are built, so are there any plans for producing a build process for the other two methods?     - Workspace/Project file     - bootstrap/config/make              (aka makefile)
     - bootstrap/dpkg-buildpackage   (aka Debian deb build)    In I have attached my work in progress build docs that cover the three methods above plus windows. These will help for the makefile and deb build processes if you are not familiar with them.
2) There are no Workspace/Project or script files in the src directory that allow you to build C::B with wxWidgets 3.1.x , are these missing or not done yet?
3) Do you need to build wx3.1.x or can you use the unofficial CodeLite 3.1.x wxWidget install files?4) The external src\plugins\contrib\FortranProject project currently supports wx3.0.x. Are there plans to ask the maintainer to support wx3.1.x or are you going to do it and give the update to the maintainer? The plugin main web site is
5) I would grab the latest SF code and make the same changes from as this is a very recent change that affected the unix wx3.0 files.

Just a thought: Miguel has been gradually been incorporating wx3.2 support into the SF trunk and as such it may be easier to get changes into the SF trunk if they were for wx3.2.
Development / Leap-15.3 : wx-315 for cb12673
« Last post by LETARTARE on January 22, 2022, 10:33:28 pm »
I just finished adapting 'cb12673' with 'wx-3.1.5' on Leap-15.3.
I attach the corresponding patch.
The following plugins are not taken into account ( they do not have *-30-unix.cbp):
   - Addr2line
   - cbLauchner
   - devPack
   - Python
   - tydycmt

I hope this helps ?
Nightly builds / Re: The 22 January 2022 build (12672) is out.
« Last post by Miguel Gimenez on January 22, 2022, 08:40:19 pm »
I do not see changes directly related to your problem, the only candidate would be 12661 but it does not mess with global variables.

Can you post yur path?

Can you build C::B?. If so, change this (in sdk/compiler.cpp:1346)
        wxSetEnv("PATH", path);
        wxSetEnv("PATH", path+origPath);

recompile and test codeblocks.exe from the devel31 folder. If this does not work you can do a bisection.
Plugins development / Re: Code completion using LSP and clangd
« Last post by Pecan on January 22, 2022, 07:48:04 pm »

I have make a simple wiki page:

CB Clangd Client - Code::Blocks


Thanks, Someday I'll get a chance to add more info.
Using Code::Blocks / Re: Using CodeBlocks to debug itself.
« Last post by everSome on January 22, 2022, 06:38:12 pm »
As to what I've done, I ended up throwing a nightly into Mercurial to monitor what I found necessary to change, and then just export those changes and then import them into the next nightly I want to compile. Using CodeBlocks_wx31_64.cbp  on my windows 10 system with only MSYS2 installed has problems. First windows, at least on my system, doesn't have zip or strip, and the xcopy that it does have takes its options after arguments, not before them. For xcopy, some places I've replaced it with cp, but in other places I repositioned the options to the end of that xcopy command and let window deal with it.   MSYS2 does provide versions of zip and strip, as well as a unix type mkdir that can be used to replace windows md and mkdir. While one can hardcode where these various parts reside (which is what I did initially), it is better to let MSYS2 decide where they are. I've come to understand that MSYS2, being a Cygwin fork, has it's Cygwin executable components in

and it's native components in
C:\msys64\ucrt64\bin, C:\msys64\mingw64\bin, etc.

The trick is to pass everything intended for MSYS2 through a MSYS2 login bash shell. To do this I'm using two custom variables which I define for each of the MSYS2 compilers I want to use be it gcc-msys2-mingw64, gcc-msys2-ucrt64, etc. The last one of course is my own creation. For that matter I've made compiler_... and options_... for clang64 as well. Rather arbitrarily, I've called them MSC and MSD. The value of these keys are what is within the the following quotes but does not include them, namely

"$(TARGET_COMPILER_DIR)..\usr\bin\env MSYSTEM=UCRT64 CHERE_INVOKING=1 /usr/bin/bash -lc '"
"$(TARGET_COMPILER_DIR)..\usr\bin\env MSYSTEM=MINGW64 CHERE_INVOKING=1 /usr/bin/bash -lc '"
"$(TARGET_COMPILER_DIR)..\usr\bin\env MSYSTEM=CLANG64 CHERE_INVOKING=1 /usr/bin/bash -lc '"
The value for  the key MSD is just "'".

This makes things like the following work:
<Add after="$(MSC)mkdir -p devel31_64/share/CodeBlocks$(MSD)" />
<Add after="$(MSC)./update.bash 31_64$(MSD)" />

The caveat being you can only use double quotes here because single quotes are used in the MSC and MSD compiler variables to denote the command being sent to bash.

The CHERE_INVOKING=1 variable keeps bash from changing  the current working directory to your login
directory, and the value of MSYSTEM tells bash which native subsystem to look in first before resorting to /usr/bin, or then windows. The appropriate values for MSYSTEM can be found in the file:
of a typical MSYS2 installation.

I would have liked to have found a way to define these MSC and MSD compiler variables in the compiler_... options... files, but have only found them to be saved in your AppData\Roaming\CodeBlocks\default.conf and then loaded therefrom or specified through the CodeBlocks UI.

Note that I've avoided changing the surrounding environment as little as possible. Thus the "./update.bash" rather than "update.bash" as that would require one to change their PATH definition to include the current directory. I've not mentioned it, but I have within the "Debugger settings" window created Configurations for each of the MSYS2 compilers named with the ID for that compiler and set the executable path within that configuration to something like "C:\msys64\mingw64\bin\gdb.exe", etc., and then in the "Compiler settings" window, in the "Program Files" subtab of the "ToolChains executable" tab, set the "Debugger" selection to the appropriate Debugger configuration that I just created, for instance:
"GDB/CDB debugger: gcc-msys2-mingw64"
sans the quotation marks.

Not liking to have to depend on defaults, I personally run the following in a MSYS2 terminal window,

cd CodeBlocks/codeblocks-code-r12661-trunk/src
find . -name '*31_64.cbp' -exec sed -i 's/compiler="gcc"/compiler="gcc-msys2-ucrt64"/' {} \;

But setting one of the MSYS2 compilers to be the default compiler should also work.

Now that I'm sending all the MSYS2 stuff through bash, I should try putting the Reverse Solidus (aka backslash)
back in to see if bash will convert them to unix style file paths required by the MSYS2 command .exe files.
Nightly builds / Re: The 22 Januari 2022 build (12672) is out.
« Last post by eckard_klotz on January 22, 2022, 06:11:39 pm »
Dear All.

I wish you a happy and healthy new year.

Thanks to all developers for the ongoing effort in the further development of Code::Blocks.

Unfortunately with this nightly (12672) Code::Blocks is not able any more to deal with a compiler-configuration that is based on global variables.

I use global variables to define all properties necessary to configure the "Compiler Toolchain Executables"
Furthermore I use different "conf" files and call Code::Blocks like this:
  • codeblocks.exe --personality="ask"

The result is that Code::Blocks provides me a choice-list that allows me to start it with one of several different compiler configurations.
For this I do all adjustments in the global variables of the associated "conf" file and I don't use the automatic compiler-detection.

Now I recognized that with this nightly (12672) Code::Blocks seems not be able to deal with the use of the global variables to configure the "Compiler Toolchain Executables" any more.
  • It is showing at the beginning a dialogue, that lists all automatically found and not found build-suits and it is not able to cancel it.
  • The result of this is that most of the global variables in the configuration of the "Compiler Toolchain Executables" will be replaced by hard content (directories and executable names).
  • Unfortunately this is not only an optical effect in the "Compiler Toolchain Executables" dialogue. But the corresponding "conf" file will be modified in the same way.

For me it is very essential to do the configuration of the "Compiler Toolchain Executables" based on global variables
  • The same global variables will be used for other configurations in the project files.
  • As long this global variables are used everywhere, a reconfiguration has to be done only once in the settings of the global variables.
  • If the uses of global variables for the "Compiler Toolchain Executables" is not possible any more, a second reconfiguration here has to be done extra.
  • It is just a question of time when double configuration runs in maintenance problems.

The issue occurs not with the nightly before (12655)

I attached some screenshots and the original "conf" file that contains the global variable based configuration of the "Compiler Toolchain Executables".

We have already discussed a similar issue associated with this here:

I'm working on Windows 7.

Please stay well and healthy,
                                        Eckard Klotz.

Nightly builds / Re: The 22 January 2022 build (12672) is out.
« Last post by killerbot on January 22, 2022, 05:43:09 pm »
solved :-)
Pages: 1 2 [3] 4 5 6 7 8 ... 10