New Variable to support wx-config in MSys2 MinGW

[ollydbg]

I have come across two issues as described below:


WX_CONFIG Library usage
Cannot build SDK target using what I think is the standard using the library linker tag as follows:
    You cannot use the following
        <Add library="`$(WX_CONFIG) --libs std,aui,propgrid`" />
    You need to use this
        <Add option="`$(WX_CONFIG) --libs std,aui,propgrid`" />

I see no difference between what you say works and not works.

Tim S

I think they are different options:

For example:

Code

				<Linker>
					<Add option="`$(WX_CONFIG) --libs std,aui`" />
					<Add option="-Wl,--no-undefined" />
					<Add library="codeblocks" />
				</Linker>

The "Add library" told C::B that a library named "codeblocks" will be linked, C::B will generate the correct linker command line option.
While, the "Add option" let the user directly put the linker command line option.

[ollydbg]

Additional Paths issue and potential changes required:
When you include $(TARGET_COMPILER_DIR)../usr/bin in the "Additional Paths" option in the global Compiler setting then on Windows any existing project that includes the zip command in the <ExtraCommands /> you will need to change the directory delim '\' to '/' if you are using the '/' delim as you will now use the MSYS2 usr/bin/zip instead of your existing windows zip file.

This is a bad issue, in-fact, we just need sh.exe in the path "$(TARGET_COMPILER_DIR)../usr/bin" to run the wx-config script.
using the usr/bin/zip is only expected when we run the update script under mingw64 shell.

[stahta01]

Additional Paths issue and potential changes required:
When you include $(TARGET_COMPILER_DIR)../usr/bin in the "Additional Paths" option in the global Compiler setting then on Windows any existing project that includes the zip command in the <ExtraCommands /> you will need to change the directory delim '\' to '/' if you are using the '/' delim as you will now use the MSYS2 usr/bin/zip instead of your existing windows zip file.

This is a bad issue, in-fact, we just need sh.exe in the path "$(TARGET_COMPILER_DIR)../usr/bin" to run the wx-config script.
using the usr/bin/zip is only expected when we run the update script under mingw64 shell.

AndrewCot seems to think converting Windows CB projects to run under MSys2 makes sense!
It does NOT! I am guessing he rarely uses the Linux CB projects because he is not understanding that the Linux projects has the same "flaws" as the MSys2 projects has.

Tim S.

[MortenMacFly]

AndrewCot seems to think converting Windows CB projects to run under MSys2 makes sense!
It does NOT! I am guessing he rarely uses the Linux CB projects because he is not understanding that the Linux projects has the same "flaws" as the MSys2 projects has.

I agree. The way forward could be to use the Unix project files under MSYS2. Shouldn't these work right out-of-the-box?
(Besides: Can anybody tell me why exactly it is worth putting energy into MSYS 2 support? I might have missed it. In the end you can do everything from native Windows, incl. using the MSYS compilers, which is what I do from time-to-time?!)

[stahta01]

AndrewCot seems to think converting Windows CB projects to run under MSys2 makes sense!
It does NOT! I am guessing he rarely uses the Linux CB projects because he is not understanding that the Linux projects has the same "flaws" as the MSys2 projects has.

I agree. The way forward could be to use the Unix project files under MSYS2. Shouldn't these work right out-of-the-box?
(Besides: Can anybody tell me why exactly it is worth putting energy into MSYS 2 support? I might have missed it. In the end you can do everything from native Windows, incl. using the MSYS compilers, which is what I do from time-to-time?!)

I have tried a few times to do an Code::Blocks IDE package for MSys2 and failed on the first try; current try builds; but, fails to run.
This time it was just to test my wxWidgets MSys2 package to verify it works with CB Projects.

I would like to get the scripted wizard working better with MSys2 mingw64; but, using MSys2 MinGW64 to build Code::Blocks might be best done the normal way (using cmd.exe prompt) instead of an MSys2 MinGW64 prompt.

Tim S.

[AndrewCot]

Let me be polite and say if you have no idea it is better to say so or nothing than to accuse someone of something that is completely wrong.

[BlueHazzard]

Can anybody tell me why exactly it is worth putting energy into MSYS 2 support

I personally think it is a great way to have a package manager with libraries that just work on windows. I need some library pacman -S and the library and all dependencies are there.
I think people nowadays use vcpck or cocoa but the first is a microsoft thing and i am not a big fan about it, and i tested the second when it was still new and it was not really nice to use, so i was stuck with msys2
Do not view it as a unix environment on windows, view it as a package manager. And for this it would be nice to have codeblocks as package there... You want to install codeblocks? Simply run pacman -S codeblocks and everything works...
If it makes sense to port windows project files or use unix project files, that is out of my scope...

[New Pagodi]

Also, if you can get codeblocks running with the GTK backend on windows, that might be the easiest way to add darkmode support that has been requested several times.  The shortest path to wxGTK on windows is probably through msys.

[ollydbg]

Also, if you can get codeblocks running with the GTK backend on windows, that might be the easiest way to add darkmode support that has been requested several times.  The shortest path to wxGTK on windows is probably through msys.

I have never used the wxGTK under Windows before, can some one shows the difference between wxGTK and wxMSW under Windows?

[stahta01]

Also, if you can get codeblocks running with the GTK backend on windows, that might be the easiest way to add darkmode support that has been requested several times.  The shortest path to wxGTK on windows is probably through msys.

I have never used the wxGTK under Windows before, can some one shows the difference between wxGTK and wxMSW under Windows?

If you will take over the maintenance of it; I will create an core CB project using wxGTK-gtk3.
You would have to do the other CB projects.

Edit: Or, if you can tell me which wxWidgets sample will show the difference I could do that, instead.

Tim S.

[ollydbg]

The discussion was in year 2022, but it looks like I need to make a conclusion in year 2024.

1, I can define a global compiler variable(gcv) in the "Menu->Settings->Global variables" dialog.

If I'm using msys2's gcc, and the library is installed by pacman, I can set a gcv named wx_config like below:

Code

wx-config-msys2.exe --prefix=$(TARGET_COMPILER_DIR)

If I'm using a wx library build myself, and I can set the wx_config gcv like below:

Code

wx-config.exe --prefix=E:/code/wxWidgets-3.2.4 --wxcfg=gcc_dll/mswud --debug

Note that the "--debug" option or the "--wxcfg=gcc_dll/mswud" depends on what kinds of wx library did you built. Maybe you are using release build, so the "--debug" option can be removed, and the correct option could be: "--wxcfg=gcc_dll/mswu".


2,
Now, in your cbp build options, you need to write such options:

For compiler options, you can write:

Code

`$(#WX_CONFIG) --cflags`

For resource compiler options, you can write:

Code

`$(#WX_CONFIG) --rcflags`

For linker options, you can write:

Code

`$(#WX_CONFIG) --libs all`

Note either wx-config.exe or wx-config-msys2.exe was built from the

eranif/wx-config-msys2: wx-config tool for MSYS2 based installation of wxWidgets using the mingw64 repository


BTW:

It looks like when using a gcv, the "#" should be used, so the below command will cause errors.

Code

`$(WX_CONFIG) --libs all`

BTW2:

You must use the Backtick in the compiler options.