Code::Blocks Forums
User forums => Nightly builds => Topic started by: killerbot on October 01, 2022, 05:05:21 pm
-
We switched to wx 3.2.1 (on 01 October 2022) --> 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 (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/wxmsw32u_gcc_cb_wx321_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 01 October 2022 build is out.
- Windows :
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2022/CB_20221001_rev12932_win64.7z
- Linux :
none
The current SDK version is : 2.22.0
Resolved Fixed:
- wxSmith: Fix blurry tool icons in HiDPI on wxWidgets >= 3.1.6
- Debugger: Fix pane's button sizes with HiDPI for wxWidgets >= 3.1.6.
- CodeCompletion: Remove all project's parsers (ticket #1316, thanks Christo).
- Reduce start time using SVG for message pane icon.
- ThreadSearch: Fix HiDPI with wxWidgets >= 3.1.6.
Regressions/Confirmed/Annoying/Common bugs:
-
WX 3.2.1
-
Downloaded and installed Nightly 12932. It executes correctly. Already had wx 3.2.1 on my Windows 10 (64-bit) platform.
Built a 64-bit version of C::B 12932 from source using Msys2. Attempting to run it, I got three dialog boxes telling me that Codeblocks.exe couldn't find an entry point in Codeblocks.exe, codeblocks.dll or wxmsw32u_gcc_custom.dll, and then exiting.
The only apparent differences readily noticeable were the sizes of wxmsw32u_gcc_custom.dll and wxmsw32u_gl_gcc_custom.dll between my version and the Nightly version. My versions of those DLL files were substantially larger.
Any ideas as to why wx 3.2.1 libraries would have different size DLL files on different platforms?
-
Downloaded and installed Nightly 12932. It executes correctly. Already had wx 3.2.1 on my Windows 10 (64-bit) platform.
Built a 64-bit version of C::B 12932 from source using Msys2. Attempting to run it, I got three dialog boxes telling me that Codeblocks.exe couldn't find an entry point in Codeblocks.exe, codeblocks.dll or wxmsw32u_gcc_custom.dll, and then exiting.
The only apparent differences readily noticeable were the sizes of wxmsw32u_gcc_custom.dll and wxmsw32u_gl_gcc_custom.dll between my version and the Nightly version. My versions of those DLL files were substantially larger.
Any ideas as to why wx 3.2.1 libraries would have different size DLL files on different platforms?
Make sure that wxWidgets and CodeBlocks are built with the same compiler.
-
the debug symbols are kicked out on the one of the nightlies, a strip pass is being executed.
-
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_20221001_rev12932_win64.zip (Direct download link (https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/ClangdClientForCBNightly_20221001_rev12932_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.
-
Hello Developers.
Great to see the ongoing work on Code::Blocks.
However I have some doubts with the icons used for write-protected files in the "open file list".
- In my nightly download they will be shown as red squares with black frames.
- But in the project tree they are still shown as normal file-symbols with a lock-symbol inside.
This is not really an issue for me.
- However, I like to ask you if this is a property of the nightly or may be an issue between my ears.
- I'm taking about the nightly: 01 October 2022 build (12932)
- I have downloaded all three provided 7z-Files and copied their content into the same bin-folder.
- I use it on a WIN 10 laptop as well as on a Win 10 desktop computer.
- To be honest I like the old icons based on normal file-symbols but with a lock-symbol inside more.
- This is a very personal view and as already mentioned if you have a different view, I will accept your decision.
- But I have more the impression that "open file list" has just problems to access the icon-definition and is using a default-icon instead.
Best regards,
Eckard Klotz.
-
The OpenFilesList plugin had a typo (missing extension in "fileread-only.png") that prevented image loading. Precisely this morning I was implementing SVG icons in the plugin and detected the problem, it is now fixed in trunk (see r12956 (https://sourceforge.net/p/codeblocks/code/12956/)).
-
Thanks for the quick reaction.
As I already mentioned it is not really an issue for me. Thus, I will wait for the next nightly.
Have a nice evening,
Eckard Klotz.
-
I have used Msys2 clang64 to compile codeblocks since r12839. I found a bug, although the problem is not very serious.
Open the [Compiler...] menu item of the [Settings] menu. In the [Toolchain executables] pane.
If you only use Custom variables to set the [Additional Paths] option, an empty string warning will pop up after restarting Codeblocks.
I found that the warning occurred in CompilerGCC::SetupEnvironment() function.
the cause of the problem is that it is not read compiler variables before calling ReplaceMacros() to replace the extrapath.
-
Fixed in [r12963], thank you.
-
Fixed in [r12963], thank you.
Your changes are a good way to avoid this warning.
Sorry. My English is not good. Maybe I didn't make it clear.
The problem should be in the MacrosManager::ReplaceMacros(wxString& buffer, const ProjectBuildTarget* target,bool subrequest) function.
MacrosManager::ReadMacros() was not called to get the contents of the compiler macro variable before the extrapath string was replaced.
I added a function to the sdk/acrosmanager file in my copies like this:
void MacrosManager::ReplaceMacros(wxString& buffer, const wxString compilerId)
{
Compiler* compiler = CompilerFactory::GetCompiler(compilerId);
ReadMacros(m_Macros, compiler);
ReplaceMacros(buffer);
}
If the second parameter directly uses the Compiler * pointer,
it may be ambiguous with MacrosManager:: ReplaceMacros (const wxString&buffer, const ProjectBuildTarget * target) overload.
And Change the code in the CompilerGCC::SetupEnvironment() function:
ReplaceMacros(extraPath);
to:
ReplaceMacros(extraPath, m_CompilerId);
I think this can ensure that the extract string can be correctly Parse and replace.
-
I can not work on this at the moment, please create a ticket (https://sourceforge.net/p/codeblocks/tickets/) with this information, because here it will disappear in a while.