Author Topic: unified workspace and cbp under Windows for different wxWidgets versions  (Read 14927 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6176
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6176
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: unified workspace and cbp under Windows for different wxWidgets versions
« Reply #1 on: 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.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9725
Re: unified workspace and cbp under Windows for different wxWidgets versions
« Reply #2 on: February 21, 2026, 07:49:07 am »
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...
« Last Edit: February 21, 2026, 07:51:08 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Wkerry

  • Multiple posting newcomer
  • *
  • Posts: 118

Offline gd_on

  • Lives here!
  • ****
  • Posts: 846
Re: unified workspace and cbp under Windows for different wxWidgets versions
« Reply #4 on: 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.1, Msys2 Compilers 15.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline Wkerry

  • Multiple posting newcomer
  • *
  • Posts: 118

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6176
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: unified workspace and cbp under Windows for different wxWidgets versions
« Reply #6 on: 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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6176
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
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.

Offline gd_on

  • Lives here!
  • ****
  • Posts: 846
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.
« Last Edit: Yesterday at 12:37:57 pm by gd_on »
Windows 11 64 bits (25H2), svn C::B (last version or almost!), wxWidgets 3.3.1, Msys2 Compilers 15.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6176
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
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.

Offline gd_on

  • Lives here!
  • ****
  • Posts: 846
Quote
So, 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.
« Last Edit: Yesterday at 02:33:04 pm by gd_on »
Windows 11 64 bits (25H2), svn C::B (last version or almost!), wxWidgets 3.3.1, Msys2 Compilers 15.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1827
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
add 	/trunk/src/plugins/contrib/FortranProject
add /trunk/src/plugins/contrib/FortranProject/FortranProject_cbsvn_Windows.cbp

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2923
What can I do about this error?

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1827
You can revert the change by ollydbg indicated in my previous message: Change to the plugins/contrib folder and run

Code
svn delete FortranProject
svn commit

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2923
What can I do about this error?
Neither TortoiseSVN nor svn will let me do that.
Code
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
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
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>
« Last Edit: Yesterday at 09:00:52 pm by Pecan »