News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

unified workspace and cbp under Windows for different wxWidgets versions

Started by ollydbg, November 09, 2025, 12:31:00 AM

Previous topic - Next topic
Print
Go Down Pages1 2 All
User actions

ollydbg

November 09, 2025, 12:31:00 AM
Hi, guys, what do you think about this?

gd_on has work on this in github repo:

codeblocks_gd_cbps

I think this is the direction we should do.

Any comments?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

#1
February 21, 2026, 04:23:14 AM
Any developer has some options about this topic?

I think the recent changes in the C::B should fully support this, see discussion here:

Re: special handling of the macro replacement ""?

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

MortenMacFly

#2
February 21, 2026, 07:49:07 AM Last Edit: February 21, 2026, 07:51:08 AM by MortenMacFly
I see the benefits from this, however, usually (at least for me) its not only the wx version that matters but also 32/64 bit and maybe a special old compiler for compatibility. For those cases it would not work unless yo very everything in the wx variable which is a bit weird. Would be great if Gerard (@gd_on) could join this conversation...

Still, it improves the situation already as it is, so I am open...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

gd_on

#4
February 21, 2026, 11:30:01 AM
Hi,
I wrote a first unified workspace and cbp, already 4 years ago and adapted it when there was important changes in the build process of C::B (new plugins, new settings for some of them...). It's an adaptation of a previous work done by AndrewCot. It works only on Windows, just because I have not linux installed, but it should be adaptable.

Everything is available on a git (https://github.com/gerard-durand/codeblocks_gd_cbps) or a svn (https://sourceforge.net/p/codeblocks-gd-cbps/svn/HEAD/tree/) repository. See also as mentionned above https://sourceforge.net/p/codeblocks/tickets/1332/.
It uses global environment variables where you can choose the wxwidgets version, the wxWidgets 32/64 bit version, cpp_flags. The choice of 32/64 bit compiler is simply made by your general compiler setting. If you want to change something, you have only to change some global variables.
Apparently, a few guys use this build system and are happy with. Of course, as you need to set global variables, it needs some knowledge and manual setting the first time you set them. But, if you follow the "Env_vars" docs carefully, it's not so difficult.
Windows 11 64 bits (25H2), svn C::B (last version or almost!), wxWidgets 3.3.2, Msys2 Compilers 16.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

ollydbg

#6
February 23, 2026, 07:04:02 AM
We can have several steps:
1, keep the old(existing) cbps and add the new unified windows cbps to the svn repo.
2, wait for several months.
3, finally those old cbps should be removed.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

#7
March 01, 2026, 03:47:04 AM
Hi, guys, I have committed the unified cbps to our svn repo, revision 13804. Thanks for the contribution, @gd_on.

Also, if you see some issues, you can report here, we can discuss and adjust. Thanks.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

gd_on

#8
March 01, 2026, 12:10:49 PM Last Edit: March 01, 2026, 12:37:57 PM by gd_on
Thanks for this publication.
Just a small remark: why almost all these cbp have linux end lines (LF). That's not a problem, but as they are for Windows, my original work has windows endlines (CR LF).

More, I think there is a problem with FortanProject plugin, beacuse as it's located outside C::B svn repository, it causes a problem when I try to update my svn synchro.
Windows 11 64 bits (25H2), svn C::B (last version or almost!), wxWidgets 3.3.2, Msys2 Compilers 16.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

ollydbg

#9
March 01, 2026, 01:28:41 PM
Quote from: gd_on on March 01, 2026, 12:10:49 PM
Thanks for this publication.
Just a small remark: why almost all these cbp have linux end lines (LF). That's not a problem, but as they are for Windows, my original work has windows endlines (CR LF).
I use "git svn" command. I mean I first add the cbp to the git repo, and later I use the git svn dcommit to push the changes to the remote svn server. I'm not sure how to fix this issue.


Quote
More, I think there is a problem with FortanProject plugin, because as it's located outside C::B svn repository, it causes a problem when I try to update my svn synchro.

So, the way it to "remove" the FortanProject plugin's cbp file from the svn trunk?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

gd_on

#10
March 01, 2026, 02:30:23 PM Last Edit: March 01, 2026, 02:33:04 PM by gd_on
QuoteSo, the way it to "remove" the FortanProject plugin's cbp file from the svn trunk?
Probably, but add the cbp to the original repos and restore the link to this repository.
Windows 11 64 bits (25H2), svn C::B (last version or almost!), wxWidgets 3.3.2, Msys2 Compilers 16.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Miguel Gimenez

#11
March 01, 2026, 04:57:04 PM
I have just added FortranProject_cbsvn_Windows.cbp to the FortranProject repository, please remove the folder and the CBP from the C::B repository so they do not clash (i.e., revert this)

Code Select

add /trunk/src/plugins/contrib/FortranProject
add /trunk/src/plugins/contrib/FortranProject/FortranProject_cbsvn_Windows.cbp

Pecan

#12
March 01, 2026, 07:42:30 PM
What can I do about this error?

Miguel Gimenez

#13
March 01, 2026, 08:29:26 PM
You can revert the change by ollydbg indicated in my previous message: Change to the plugins/contrib folder and run

Code Select

svn delete FortranProject
svn commit

Pecan

#14
March 01, 2026, 08:57:07 PM Last Edit: March 01, 2026, 09:00:52 PM by Pecan
Quote from: Pecan on March 01, 2026, 07:42:30 PM
What can I do about this error?
Neither TortoiseSVN nor svn will let me do that.
Code Select

PS F:\usr\Proj\cbDevel328WrkCC> cd .\trunk\
PS F:\usr\Proj\cbDevel328WrkCC\trunk> svn delete FortranProject
svn: E200005: Use --force to override this restriction (local modifications may be lost)
svn: E200005: 'F:\usr\Proj\cbDevel328WrkCC\trunk\FortranProject' is not under version control
PS F:\usr\Proj\cbDevel328WrkCC\trunk>


And a clean update gets the error.
Code Select
PS F:\usr\Proj\cbDevel328WrkCC\trunk> svn update
Updating '.':

Fetching external item into 'src\plugins\contrib\FortranProject':
svn: warning: W155035: The external 'https://svn.code.sf.net/p/fortranproject/code/trunk' defined in svn:externals at 'F:\usr\Proj\cbDevel328WrkCC\trunk\src\plugins\contrib' cannot be checked out because 'F:\usr\Proj\cbDevel328WrkCC\trunk\src\plugins\contrib\FortranProject' is already a versioned path.

At revision 13804.
svn: E205011: Failure occurred processing one or more externals definitions
PS F:\usr\Proj\cbDevel328WrkCC\trunk>

Even using --force does not work.
Code Select
PS F:\usr\Proj\cbDevel328WrkCC\trunk> svn delete FortranProject --force
svn: E125001: 'F:\usr\Proj\cbDevel328WrkCC\trunk\FortranProject' does not exist
PS F:\usr\Proj\cbDevel328WrkCC\trunk> svn update
Updating '.':

Fetching external item into 'src\plugins\contrib\FortranProject':
svn: warning: W155035: The external 'https://svn.code.sf.net/p/fortranproject/code/trunk' defined in svn:externals at 'F:\usr\Proj\cbDevel328WrkCC\trunk\src\plugins\contrib' cannot be checked out because 'F:\usr\Proj\cbDevel328WrkCC\trunk\src\plugins\contrib\FortranProject' is already a versioned path.

At revision 13804.
svn: E205011: Failure occurred processing one or more externals definitions
PS F:\usr\Proj\cbDevel328WrkCC\trunk>
Print
Go Up Pages1 2 All
User actions