Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
Nightly builds / Re: The 22 January 2022 build (12672) is out.
« Last post by eckard_klotz on Today at 09:02:55 am »
Hello Miguel Gimenez and AndrewCot.

I assume that you have respond to my request (but I'm not sure).

From my perspective the main issue is not the automatic tool detection. The issue is that Code::Blocks is changing the configuration of the user.

For somebody who is new in Code::Blocks and/or C/Cpp programming features like tool auto-detection are definitely very helpful, no doubt about that.
  • But if a user decides to modify the configuration this automatism must not work against the user.
  • Using global variables instead of hard-coding makes it possible to use the same global variable more than once while its definition is centralized and has to be maintained only once.

If I place in a configuration dialogue global variables (in my case the "Compiler Toolchain Executables") I actually expect that this adjustment will not be changed but kept.
  • Thus please ensure that Code::Blocks is not modifying the configuration-properties which are using global variables as value.

Is there an application parameter similar to --personality="ask" that could be used while starting Code::Blocks to suppress the auto-detection and all associated auto-configurations?
  • Consequently all auto detections may already be suppressed if Code::Blocs starts not with default.conf. after using --personality="ask".
  • In this case the user made very clear that an already prepared configuration should be used.

Please stay well and healthy,
                                         Eckard Klotz.
Updated release now available for x64.

This release has the following major changes:1. Added Pecan's experimental CB-clangd_client. See (updated to V2.0.10 as of 23JAN2022)
2. Fix SVN 12662 change so batch mode build works again (fixed on 23-Jan-2022)
Other changes:
1. Updated to latest SF CB code, SVN 12673.
Nightly builds / Re: The 22 January 2022 build (12672) is out.
« Last post by AndrewCot on Today at 06:46:22 am »
To fix batch building you need to mod src\plugins\compilergcc\compilergcc.cpp around line 1623 change it to the following to add the sBatchBuild() protection:
    if (!Manager::IsBatchBuild())

@ALL Yet again another SVN change that does not have a ticket and as such the change was not reviewed by anyone.
Nightly builds / Re: The 22 January 2022 build (12672) is out.
« Last post by AndrewCot on Today at 04:24:25 am »
I have started having issues today after updating my source tree and even tried the nightly 7z file & DLL's and cannot get batch mode working on it either.

I can build the workspace if I load it after starting C::B normally. The biggest issue I have is that the batch log does not show anything... I have tried added the following parameters to rry and get some logging, but nothing  --verbose --debug-log --log-to-file --debug-log-to-file
I went back to the 11-Jan-2022 nightly and it worked. Now I need to try the other nighties and then try to track down the bug, unless someone else finds it first.

Update #1:
1. Nightly 16JAN2022 SVN 12655 is okay
2. Local build using SVN 12659 source code is okay.

Update #2:3. Local build using SVN 12660 source code builds SVN 12661 in batch mode. So good.
4. Local build using SVN 12661 source code builds SVN 12662 in batch mode. So good.5. Local build using SVN 12662 source code fails to build SVN 12663 in batch mode. So BAD

So it looks like the changes in SVN 12662 have broken batch mode.

Development / Re: Remove coders query from plugins
« Last post by AndrewCot on Today 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 Today 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 Today 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 Today 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 Yesterday at 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 Yesterday at 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.
Pages: [1] 2 3 4 5 6 ... 10