Author Topic: The 22 January 2022 build (12672) is out.  (Read 6206 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5353
The 22 January 2022 build (12672) is out.
« on: January 22, 2022, 09:40:12 am »
We switched to wx 3.1.5 --> download the new wx dll's see link below

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.

A link to the unicode windows wxWidget dll(s) for Code::Blocks : https://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw31u_gcc_cb_wx315_2D_gcc810-mingw64.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 22 January 2022 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2022/CB_20220122_rev12672_win64.7z
  - Linux :
   none

The current SDK version is : 2.16.0

Resolved Fixed:

  • Build: Add DisplayEvents plugin to autotools.
  • Rework Drag and Drop: Complete rework of dnd in project tree and editor. Fix (Ticket #1169)
  • Do not use system path when evaluating compilers.
  • Fix missing target selection choice in compiler's toolbar (Linux with GTK3).
  • Fix compiler version detection on non-MSW systems.
  • Fix compilation of C::B with C::B using CodeBlocks_wx30-unix.workspace (tested on Ubuntu 20.04, ticket #1181).
  • DnD: Clean up code from r12660. Support DnD of files to virtual folders (fix Ticket #1170 and #1169)
  • Fix crash on MAC introduced in [r12597] (thanks Xaviou for reporting and testing).
  • Change MSW version of Compiler::Execute() so it behaves like the non-MSW version.
  • Add DisplayEvents core plugin to codeblocks.spec.in and codeblocks.spec.fedora.in (ticket #1182
  • SDK: Add Windows 10 and 11 detection to platform::WindowsVersion().
  • Project importer: Fix memory leak (thanks Andrew Cottrel for pointing it out).

Regressions/Confirmed/Annoying/Common bugs:


    « Last Edit: January 22, 2022, 05:43:00 pm by killerbot »

    Offline gd_on

    • Lives here!
    • ****
    • Posts: 707
    Re: The 22 Januari 2022 build (12672) is out.
    « Reply #1 on: January 22, 2022, 10:01:15 am »
    just because it hurts my eyes  ;D, january is with an y  ::)
    Anyway, thanks for your work  ;)
    « Last Edit: January 22, 2022, 05:50:29 pm by gd_on »
    Windows 10 64 bits (21H2), svn C::B (last version or almost!), wxWidgets 3.2.0, Msys2 Compilers 12.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (sjlj, posix in C:\msys64\mingw32).

    Offline killerbot

    • Administrator
    • Lives here!
    • *****
    • Posts: 5353
    Re: The 22 January 2022 build (12672) is out.
    « Reply #2 on: January 22, 2022, 05:43:09 pm »
    solved :-)

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 184
    Re: The 22 Januari 2022 build (12672) is out.
    « Reply #3 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.



    Offline Miguel Gimenez

    • Developer
    • Lives here!
    • *****
    • Posts: 1056
    Re: The 22 January 2022 build (12672) is out.
    « Reply #4 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)
    Code
            wxSetEnv("PATH", path);
    to
    Code
            wxSetEnv("PATH", path+origPath);


    recompile and test codeblocks.exe from the devel31 folder. If this does not work you can do a bisection.

    Offline AndrewCot

    • Lives here!
    • ****
    • Posts: 577
    Re: The 22 January 2022 build (12672) is out.
    « Reply #5 on: January 23, 2022, 12:52:18 am »
    I agree with Miguel for what it's worth.

    Offline AndrewCot

    • Lives here!
    • ****
    • Posts: 577
    Re: The 22 January 2022 build (12672) is out.
    « Reply #6 on: January 23, 2022, 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.




    « Last Edit: January 23, 2022, 06:26:07 am by AndrewCot »

    Offline AndrewCot

    • Lives here!
    • ****
    • Posts: 577
    Re: The 22 January 2022 build (12672) is out.
    « Reply #7 on: January 23, 2022, 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())
        {
            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.

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 184
    Re: The 22 January 2022 build (12672) is out.
    « Reply #8 on: January 23, 2022, 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.
    « Last Edit: January 23, 2022, 09:04:26 am by eckard_klotz »

    Offline Miguel Gimenez

    • Developer
    • Lives here!
    • *****
    • Posts: 1056
    Re: The 22 January 2022 build (12672) is out.
    « Reply #9 on: January 23, 2022, 11:57:05 am »
    @AndrewCot: Fixed in r12674

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

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 184
    Re: The 22 January 2022 build (12672) is out.
    « Reply #10 on: January 23, 2022, 12:02:01 pm »
    Hello Miguel Gimenez.

    Here you are:

    Quote
    C:\Users\Eckard>PATH
    PATH=C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x86;C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x64;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;\;C:\Program Files (x86)\Sony\VAIO Startup Setting Tool;C:\Program Files (x86)\T-Online\T-Online_Software_6\Basis-Software\Basis2\;C:\Tool\DEVELO~1\Graphiz\GRAPHV~1\bin\Graphviz\bin;C:\Tool\Development\Doxygen\DoxyGen_1_8_7\bin\bin;C:\Tool\Development\MscGen\V_0_2_0\bin\Mscgen;C:\Tool\Development\MinGW\MinGW_4_8_1_3_DW2\bin;C:\Tool\Development\MinGW\MinGW_4_9_2\bin;C:\Tool\Development\Doxygen\DoxyGen_1_8_8\bin\bin;C:\Tool\Office\LaTeX\LyX\Release\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Tool\Development\Doxygen\DoxyGen_1_8_11\release\doxygen\bin;C:\Tool\Development\Doxygen\DoxyGen_1_8_12\release\bin;C:\Tool\Development\Doxygen\DoxyGen_1_8_13\release\doxygen\bin;C:\Tool\Development\PuTTy\bin\;C:\WINDOWS\System32\OpenSSH\;C:\Tool\Development\SVN\Tortoise\Install\bin;C:\Tool\Development\GIT\Installed\cmd;C:\Tool\Development\MinGW\MinGW_9_2_0_TDM\bin_64\bin;C;C:\Tool\Office\LaTeX\CTAN\texlive\2020\bin\win32;C:\Users\Eckard\AppData\Local\Microsoft\WindowsApps;

    Best regards,
                         Eckard Klotz.

    Offline Miguel Gimenez

    • Developer
    • Lives here!
    • *****
    • Posts: 1056
    Re: The 22 January 2022 build (12672) is out.
    « Reply #11 on: January 23, 2022, 12:43:56 pm »
    Please restore your compiler toolchain configuration (with the global variables) and check if it works.

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 184
    Re: The 22 January 2022 build (12672) is out.
    « Reply #12 on: January 23, 2022, 01:46:41 pm »
    Hello Miguel Gimenez.

    Quote
    @eckard_klotz: Works here with the last version, have you tried after restoring the configuration?.
    Quote
    Please restore your compiler toolchain configuration (with the global variables) and check if it works.

    The question is what do you understand as "restoring the configuration" ?

    When I read that it is working for you I tried it again and yes you are right it was working as wanted:
    • The revision 12672 has not started the "Compilers Auto Detection" dialogue
    • The compiler settings contain all global variables as configured manually.

    The reconstruction was done based on the conf-file left by the  revision 12672 yesterday.
    • I have just replaced the literal information by the global variables.

    Now I wondered what I have done wrongly yesterday
    • I repeated step by step what I have done but with a different conf-file I have not used since August 2021.
    • Furthermore please notice, that I have used until yesterday the revision 12516 from August the 15th 2021.
    • Attached you will find a ZIP-file with screen shots and conf-files I mention in the description below.

    • I started Code::Blocks revision 12516 with the configuration "MinGW_9_2_0_64bit_TDM_Original.conf"
      • No "Compilers Auto Detection" dialogue occurred.
      • The configuration of the "Compiler Toolchain Executables" contained global variables ("CB_12516_compiler_toolchain_executables.png").
      • After closing Code::Blocks the file "MinGW_9_2_0_64bit_TDM_ref12516.conf" was stored.
    • Now I started Code::Blocks revision 12672 with the conf-file stored by the revision 12516 "MinGW_9_2_0_64bit_TDM_ref12516.conf".
      • The "Compilers Auto Detection" dialogue occurred.
      • The configuration of the "Compiler Toolchain Executables" contained not all global variables as desired but a lot of literal configurations ("CB_12762_compiler_toolchain_executables.png").
      • After closing Code::Blocks the file "MinGW_9_2_0_64bit_TDM_ref12762.conf" was stored.
      • Please notice, that this file is 3 kb larger than the original one.
    • Now I have corrected the content of the new conf-file by reconstructing the gcc configuration as present in the original conf-file.
      • I left anything else as stored by the revision 12762.
    • At the end I started Code::Blocks revision 12762 with the corrected configuration "MinGW_9_2_0_64bit_TDM_ref12672_Corrected.conf."
      • No "Compilers Auto Detection" dialogue occurred.
      • The configuration of the "Compiler Toolchain Executables" contained global variables as desired.

    OK, after a manual correction of the configurations overwritten by Code::Blocks it is keeping the global variables again.
    • For a single user this may be a workaround.
    • But the user has to check every single configuration he has done in the past to ensure not to oversee a hidden modification.
    • Furthermore, this has to be done with every revision change since the user could not know when the conf-file format was changed.

    I know where the conf-files are located on my computer:
    • C:\Users\[USER_NAME]\AppData\Roaming\CodeBlocks
    • Thus I have the chance to store the conf-files before changing the Code::Blocks revision to compare it later with the conf-files stored by the new revision
    • But how many Code::Blocks users are realy able to do the same


    Best regards,
                        Eckard Klotz.

    Offline AndyJ

    • Multiple posting newcomer
    • *
    • Posts: 21
    Re: The 22 January 2022 build (12672) is out.
    « Reply #13 on: February 03, 2022, 11:48:32 am »
    Not specific to this nightly but since the website updates the RSS link specified in the first email:

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

    now longer seems to work which is a shame as I used to find the updates on a new release useful

    Thanks for all the good work,

    Andy

    Offline Xaviou

    • Regular
    • ***
    • Posts: 352
      • X@v's wxStuff
    Re: The 22 January 2022 build (12672) is out.
    « Reply #14 on: February 03, 2022, 09:54:03 pm »
    Not specific to this nightly but since the website updates the RSS link specified in the first email:

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

    now longer seems to work which is a shame as I used to find the updates on a new release useful

    Thanks for all the good work,

    Andy
    You can use the following : http://forums.codeblocks.org/index.php?type=rss;sa=news;action=.xml;board=20;limit=10

    Regards
    Xav'
    The french wxWidgets site : http://www.wxdev.fr
    My wxWidgets's stuff : https://wxstuff.xaviou.fr/