svn rev 13798 issue?

[ollydbg]

Hi, Pecan, I see this commit:

https://sourceforge.net/p/codeblocks/code/13798/

Some of changes in the cbp files are not expected? I think the macro variable "CODEBLOCKS" is not needed here.

[Pecan]

Do you mean that it's causing an error. Where do you get the error?

What OS? What compiler? Which wxWidgets?

I can't reproduce an error. Can you give me some steps to cause the error?
Thanks

[ollydbg]

You must have the compiler global variable CODEBLOCKS defined.

But that was not necessary.  For example, if you look at this cbp file and other cbp files.

https://github.com/arnholm/codeblocks_sfmirror/blob/master/src/plugins/contrib/SmartIndent/SmartIndent_wx32_64.cbp

You don't see any CODEBLOCKS variable needed.

I'm not sure you can understand my explanations.  But this compiler macro is not needed in cbp file and the update file.

[Pecan]

$(CODEBLOCKS) is automatically defined by CB in macrosmanger. The user does not need to define it anywhere.

Are you getting errors when compiling codesnippets ?

The use of $(CODEBLOCKS) makes it easy to drag a contrib dir out of the local repo to a new separate directory and work with the contrib without .cbp changes. Then drag it back to the repo without making mistakes trying to fix the .cbp file. No changes, no mistakes.

Without using the macro, you cannot use the repo .cbp without making ../../.. changes all over the place, It  is much easier to use $(CODEBLOCKS)\..\ without making any changes to the .cbp(s) and the macro is build into the sdk source code builtin variables.
https://wiki.codeblocks.org/index.php/Variable_expansion

[ollydbg]

First, this "CODEBLOCKS" is defined here:

Code

void MacrosManager::ClearProjectKeys()
{
    m_Macros.clear();

    m_Macros[_T("AMP")]        = _T("&");
    m_Macros[_T("CODEBLOCKS")] = m_AppPath;
    m_Macros[_T("APP_PATH")]   = m_AppPath;
    m_Macros[_T("APP-PATH")]   = m_AppPath;
    m_Macros[_T("APPPATH")]    = m_AppPath;
    m_Macros[_T("DATA_PATH")]  = m_DataPath;
    m_Macros[_T("DATA-PATH")]  = m_DataPath;
    m_Macros[_T("DATAPATH")]   = m_DataPath;
    m_Macros[_T("PLUGINS")]    = m_Plugins;
    m_Macros[_T("LANGUAGE")]   = wxLocale::GetLanguageName(wxLocale::GetSystemLanguage());
    m_Macros[_T("ENCODING")]   = wxLocale::GetSystemEncodingName();

But in my build environment, it can't be used.

Here is my situations:

1, I use a C::B(let's say it is the host C::B) to open and build C::B workspace. The build result is the client C::B.
2, The host C::B is usually download from my github action release which is using the latest release version of wx 3.3.1 and latest msys2, and the C runtime is UCRT.
3, The client C::B is usually link to the debug version of the wxWidgets. In my local PC, I have build debug version of wx 3.3.1 myself under gcc compiler(msys2, but the C runtime is MSVCRT, because some of my clients are still using Windows 7) to track errors.

If using $(CODEBLOCKS) method, I have to link the client C::B's plugin against the host C::B, that is not possible. Because they use different wxWidgets library, different GCC version, different C runtime library.

[gd_on]

Is there a way to display within Code::Blocks the content of environment variables that are set by MacrosManager, so AMP, CODEBLOCKS, APP_PATH, ...

[Miguel Gimenez]

Is there a way to display within Code::Blocks the content of environment variables that are set by MacrosManager, so AMP, CODEBLOCKS, APP_PATH, ...

I do not think so. There is a MacrosManager::GetMacros() method, currently unused, that would make easy to add this information to a tab in the About dialog (for example). This way the user does not have to search the Wiki.

[Pecan]

I've reverted the use of built-in variables in the codesnippets.cbp.

Sadly, this means we can never  use the built-in macros in a .cbp file.

[Pecan]

Is there a way to display within Code::Blocks the content of environment variables that are set by MacrosManager, so AMP, CODEBLOCKS, APP_PATH, ...

Would displaying the built-in vars within Code::Blocks allow us to use them in .cbp files?
Would that avoid the problems experienced by ollydbg?