codeblocks cbp projects for wx samples

[ollydbg]

Hi, I have some friends who are willing to learn wx by wxWidgets' samples.

I can ask them to use Code::Blocks, while, I think the best way to learn is using wx samples from the official wx git repo (This is not only for beginner, also for testing some wx features):

https://github.com/wxWidgets/wxWidgets/tree/master/samples

My idea is we can supply some C::B cbp files for the samples, I see tim has some contribution:

stahta01/msys2_wxwidgets_cb_projects: CB wxWidgets projects using msys2
This repo contains about 10 samples, but not the full wx samples.

I think either using msys2's pre-build library or self build wx library is OK, so are there any suggestions?

Thanks.


EDIT

I found an old reop which is also by tim
stahta01/cb_projects_for_wxWidgets: Code::Blocks projects for building wxWidgets sample code
It was several years ago, and it use the wx-config.exe.

EDIT2

It looks like wx has cmake support, see this document: wxWidgets: CMake Overview
So, maybe we can use official cmake to generate the codeblocks cbp for each samples?


EDIT3
As 2022-09-17, I create a git repo: asmwarrior/cb_projects_for_wxWidgets: Code::Blocks projects for building wxWidgets sample code, which supples Code::Blocks project files(cbp) for each wx sample (wxWidgets 3.2.1), and with the help of wx-config-msys2.exe (from eranif/wx-config-msys2: wx-config tool for MSYS2 based installation of wxWidgets using the mingw64 repository), it can build wx samples under Code::Blocks and link to the prebuild wx library(wxWidgets 3.2) in msys2.


EDIT4
As 2022-10-09
You can tweak the wx-config variable in your C::B, which can use either the wx library supplied by msys2, or you can using the wx library built by yourself by the "makefile.gcc", see this reply for details.
Re: codeblocks cbp projects for wx samples

[stahta01]

EDIT2

It looks like wx has cmake support, see this document: wxWidgets: CMake Overview
So, maybe we can use official cmake to generate the codeblocks cbp for each samples?

I spent about one hour trying that; but, I gave up the cmake support files needed was too old in the MSys2 cmake I had.
I might try again; but, right now I am working on building MINGW64 GCC variants and failing.

I do think it is a best long term way to proceed; but, I need to learn the new wxWidgets cmake way and find the correct cmake support files.

From https://docs.wxwidgets.org/3.2.0/overview_cmake.html

Recommendations
While CMake in wxWidgets aims to support most generators available in CMake the following generators are recommended:

Windows: Visual Studio (any supported version)
macOS: Xcode
Linux: Ninja or Makefiles
CMake 3.10 or newer is recommended. The minimum version required is 2.8.12.

I was not using one of the recommended way; I might try Ninja on my next attempt.

Tim S.

[sodev]

Last time i checked (2 or 3 months ago) the CMake way produced a quite ugly result regarding the samples, at least using Visual Studio and Ninja, every sample got placed into one common directory.

[ollydbg]

Hi, thanks for the time and help.

I would like to find a simple way, here is my try steps:



I try to create a cbp file which use the makefile.gcc under the sample/minimal folder.

I add the line

Code

makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb

Because I built wx library with the command:

Code

mingw32-make -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb

Now, I have a "all" build target of the cbp file.

When I click the "build" button, I got this:

Code

-------------- Build: all in minimal (compiler: GNU GCC Compiler)---------------

[100.0%] Checking if target is up-to-date: mingw32-make.exe -q -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb all
Running command: mingw32-make.exe -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb all
process_begin: CreateProcess(NULL, F:/msys2/mingw64/bin/ -c "if not exist gcc_mswudll mkdir gcc_mswudll", ...) failed.
make (e=5): 拒绝访问。
mingw32-make: [makefile.gcc:206: gcc_mswudll] Error 5 (ignored)
if not exist gcc_mswudll mkdir gcc_mswudll
windres -i../../samples/sample.rc -ogcc_mswudll\minimal_sample_rc.o    --define __WXMSW__   --define NDEBUG    --define _UNICODE --include-dir .\..\..\lib\gcc_dll\mswu --include-dir ./../../include  --include-dir . --define WXUSINGDLL --define wxUSE_DPI_AWARE_MANIFEST=2 --include-dir ./../../samples --define NOPCH
windres: gcc_mswudll\minimal_sample_rc.o: No such file or directory
mingw32-make: *** [makefile.gcc:224: gcc_mswudll\minimal_sample_rc.o] Error 1
Process terminated with status 2 (0 minute(s), 0 second(s))
3 error(s), 0 warning(s) (0 minute(s), 0 second(s))
 

The Chinese text means "access deny".

When I look at the makefile.gcc, I see this line:

Code

$(OBJS):
   -if not exist $(OBJS) mkdir $(OBJS)

This means the makefile does not work correctly under C::B, while I see it works correctly under Windows cmd.
Here is the log under Windows CMD

Code

F:\code\wxWidgets-3.2.1\samples\minimal>mingw32-make -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb all
if not exist gcc_mswudll mkdir gcc_mswudll
windres -i../../samples/sample.rc -ogcc_mswudll\minimal_sample_rc.o    --define __WXMSW__   --define NDEBUG    --define _UNICODE --include-dir .\..\..\lib\gcc_dll\mswu --include-di
r ./../../include  --include-dir . --define WXUSINGDLL --define wxUSE_DPI_AWARE_MANIFEST=2 --include-dir ./../../samples --define NOPCH
g++ -c -o gcc_mswudll\minimal_minimal.o  -O2 -mthreads -D__WXMSW__   -DNDEBUG    -D_UNICODE -I.\..\..\lib\gcc_dll\mswu -I.\..\..\include  -W -Wall -I. -DWXUSINGDLL -I.\..\..\sample
s -DNOPCH   -Wno-ctor-dtor-privacy   -MTgcc_mswudll\minimal_minimal.o -MFgcc_mswudll\minimal_minimal.o.d -MD -MP minimal.cpp
g++ -o gcc_mswudll\minimal.exe @gcc_mswudll\minimal.exe.rsp   -mthreads -L.\..\..\lib\gcc_dll  -Wl,--subsystem,windows -mwindows        -lwxmsw32u -lwxscintilla -lwxtiff -lwxjpeg -
lwxpng   -lwxzlib -lwxregexu -lwxexpat   -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lshell32 -lshlwapi -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lve
rsion -lws2_32 -lwininet -loleacc -luxtheme

So, it looks like a wrong shell is called? or any solutions?

Thanks.

EDIT: problem solved!

The problem is that I have a path:

Code

$(TARGET_COMPILER_DIR)../usr/bin

In the compiler's extra path. I just remove this line, and restart C::B, and it is OK now.


EDIT2:

I think this issue has already mentioned by AndrewCot, because I have put the msys' shell path usr/bin to the mingw64/bin path. Though I can use the sh.exe to call the wx-config script, but this also cause this issue.

[ollydbg]

I think creating makefile based cbp is simple. but there is one drawback when using makefile based cbps. 

That is: code completion plugin/clangd_client plugin doesn't know the include search paths, so no code navigation/code completion.

[AndrewCot]

My thought, which may be wrong or off topic or just plain not feasible/workable follows:

Instead of getting the users to build a monolithic wxWidgets on Windows would it not be easier to use the MSYS2 wxWidgets 3.2.0 package? This would then mean that the C::B project files would use the wx-config and therefore the resulting files would be very similar on Windows & Linux & Mac. It wouild also hopefully make it less confusing for the newbies as Linux and MAC use the wxWidgets packages instead of having to build wxWidgets. The resulting project file(s) should in theory be easy to make cross platform once you get it working on one OS.
You can have one project file work on Linux and MAC if you use a global variable to configure the call to wx-config as it is different for them, but the way wx-config works is the same for what I have done so far (I have a common set of project files that build C::B on Linux and MAC by changing a global variable.)

[ollydbg]

My thought, which may be wrong or off topic or just plain not feasible/workable follows:

Instead of getting the users to build a monolithic wxWidgets on Windows would it not be easier to use the MSYS2 wxWidgets 3.2.0 package? This would then mean that the C::B project files would use the wx-config and therefore the resulting files would be very similar on Windows & Linux & Mac. It wouild also hopefully make it less confusing for the newbies as Linux and MAC use the wxWidgets packages instead of having to build wxWidgets. The resulting project file(s) should in theory be easy to make cross platform once you get it working on one OS.
You can have one project file work on Linux and MAC if you use a global variable to configure the call to wx-config as it is different for them, but the way wx-config works is the same for what I have done so far (I have a common set of project files that build C::B on Linux and MAC by changing a global variable.)

I agree with you. Using the prebuild wxWidgets library supplied by MSYS2 is better than selfbuild wx library.

But how can we use wx-config under Windows(MSYS2)?

You mean under C::B, we have to use the sh.exe to call the wx-config script under msys2?
Or, we can use "wx-config-msys2.exe" which is designed by eranif, this executable can directly be called without the sh.exe.

Which method do you suggest?

I don't know how easy to create such sample cbp files for each wx samples.

[AndrewCot]

I have created some MSYS2 specific project files that use the wx-config and found it's not easy in that like you found out if you forget to remove the additional path it causes problems.

I did not think of eranif's wx-config-msys2.exe. If it works then it would remove the need for the additional path and would probably the best solution if it works. I should try it with the MSYS2 C::B project files I created for some testing I did.


I have created a bunch of project files for plugins that do not have any for Linux. I pick an existing one and remove the file list and save it as a "template" and then copy it into the directory I want it in. I add the files and update it  via Notepad++ as it is quicker than using C::B. Once I have it done I then open it in C::B and fix the build issues due to missing stuff or changes for the new directory, which I then feed into the template for the next project.

[ollydbg]

I have created some MSYS2 specific project files that use the wx-config and found it's not easy in that like you found out if you forget to remove the additional path it causes problems.

I did not think of eranif's wx-config-msys2.exe. If it works then it would remove the need for the additional path and would probably the best solution if it works. I should try it with the MSYS2 C::B project files I created for some testing I did.

eranif's wx-config-msys2.exe works correctly. I use it for some of my personal wx based projects.
What you need to do is adding something like:

Code

`wx-config-msys2 --libs all --prefix=$(TARGET_COMPILER_DIR)`
or
`wx-config-msys2 --cflags --prefix=$(TARGET_COMPILER_DIR)`

In the compiler or linker options.

I have created a bunch of project files for plugins that do not have any for Linux. I pick an existing one and remove the file list and save it as a "template" and then copy it into the directory I want it in. I add the files and update it  via Notepad++ as it is quicker than using C::B. Once I have it done I then open it in C::B and fix the build issues due to missing stuff or changes for the new directory, which I then feed into the template for the next project.

Yes, this is a workaround. I also did the similar things, especially I would like to test some wx sample code. I'm not satisfied with this method. Especially for wx and C::B beginner.

[ollydbg]

Today, I see someone post a wx-config.bat script in the wxWidgets forum, see here:
MSYS2 wx-config from command prompt (CMD) workaround / fix

If we don't need to put the "usr/bin" to the PATH, this may be a good method. I will try it.

EDIT:

It looks this method works, but not under Win7, see my reply here: Post

[AndrewCot]

I have been playing with wx-config-msys2 source and have got it sort of working in building C::B. I have created a C::B project for it and added it to my msys C::B workspace.


I need to first build the wx-config-msys.exe before I can then use it via a global variable. Once wx-config-msys.exe exists I then need to reload the workspace before I can then build C::B.

I need to look at the backticks expansion and see where the project file backtick expansion occurs as the expansion needs to occur at project compile time rather than at project load time. My guess is that currently the expansion occurs when the project is loaded loaded and as the  wx-config-msys.exe file does not exist then the expansion does not work or is an empty string. I need to investigate this as it is not currently working properly IMHO.

This is an example of my usage and variable setup:
Example project settings:

Code

        <Compiler>
            <Add option="`$(#WXWIDGETS.WX_CONFIG) --cflags`" />
        </Compiler>
        <Linker>
            <Add option="`$(#WXWIDGETS.WX_CONFIG) --libs std,aui,propgrid`" />
        </Linker>

#WXWIDGETS.WX_CONFIG setting:

Code

D:\Andrew_Development\Work_Installers\CodeBLocks_Private_Experimental_GCC\src\devel32_64\wx-config-msys2.exe --prefix=$(TARGET_COMPILER_DIR)

[ollydbg]

Hi, AndrewCot, nice work!

I think using the global compiler variable is better and more flexible than putting the wx-config-msys2.exe directly in the linker or compiler options.

Maybe it can have cross-platform support.

If you look at the generated exe file of eranif's project, it has a wx-config.exe which supports local(self built) wx library, and wx-config-msys2.exe support msys2's prebuild wx library. So, just change the #WXWIDGETS.WX_CONFIG setting in different cases.

[AndrewCot]

I use a #WXWIDGETS.WX_CONFIG global variable that I change to build Linux or Mac for the one set of project files. Once I get the wx-config-msys2.exe building and runnign in the one project file I will have a look at the wx-config.exe as it will simplify the project files and allow me to merge my current two sets of Windows project files back into one set, which is allot more manageable and makes updates/changes allot easier.In the long run I hope (I can wish) that only one set of project files will be needed, but there are issues with the <ExtraCommands> , <Compiler> and <Linker> which have different options for the Windows compared to Linux/Mac.

[ollydbg]

EDIT

I found an old reop which is also by tim
stahta01/cb_projects_for_wxWidgets: Code::Blocks projects for building wxWidgets sample code
It was several years ago, and it use the wx-config.exe.

I think tim's this repo could be a start work base.

I see in each cbp file of this repo, it has something like:

Code

			<Target title="win_gcc">
				<Option output="bin/$(TARGET_NAME)/$(PROJECT_NAME)" prefix_auto="1" extension_auto="1" />
				<Option object_output=".objs/$(TARGET_NAME)" />
				<Option type="0" />
				<Option compiler="gcc" />
				<Option projectLinkerOptionsRelation="2" />
				<Compiler>
					<Add option="`$(WX_CONFIG) --cflags`" />
				</Compiler>
				<Linker>
					<Add option="`$(WX_CONFIG) --libs std,ribbon`" />
				</Linker>
				<Environment>
					<Variable name="WX_CONFIG" value="wx-config --compiler=gcc --wxcfg=$(WXCFG)" />
				</Environment>
			</Target>

Here, tim use the "WX_CONFIG" variable. This variable is cbp dependent, I think a better method is using the C::B's global compiler variable, such as #WXWIDGETS.WX_CONFIG

So, basically, what I need to do is:

1, remove the <Environment> section.
2, change the $(WX_CONFIG) to #WXWIDGETS.WX_CONFIG
3, add a gcv, which point the #WXWIDGETS.WX_CONFIG to the correct wx-config-msys2.exe or wx-config.exe
4, update tim's repo code in samples to the latest wx 3.2.1

[ollydbg]

Here are some news:

I have a fork from Tim's repo, and I have used the gcv(global compiler variable) WX_CONFIG

Some of samples are updated and worked fine by using the wx-config-msys2.exe and the 3.2.0 library inside the msys2 mingw64 toolchain.

Here is the commit history:
Commits asmwarrior/cb_projects_for_wxWidgets

I'm not sure there is a find/replace method to do all the jobs, currently, I just manually edit the cbp file from C::B the build option dialog.

Some extra issue: when I try to start the generated application exe file, it looks like the starting directory is not correct. (a messagebox will be shown).

EDIT:
My WX_CONFIG setting is:

Code

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