User forums > Nightly builds

The 22 January 2022 build (12672) is out.

<< < (2/4) > >>

AndrewCot:
I agree with Miguel for what it's worth.

AndrewCot:
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.

AndrewCot:
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())
    {
        m_pTbar->Fit();
    }

@ALL Yet again another SVN change that does not have a ticket and as such the change was not reviewed by anyone.

eckard_klotz:
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.

Miguel Gimenez:
@AndrewCot: Fixed in r12674

@eckard_klotz: Works here with the last version, have you tried after restoring the configuration?. Please post your path.

Navigation

[0] Message Index

[#] Next page

[*] Previous page