Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Contributions to C::B => Topic started by: PB on May 21, 2021, 06:15:41 pm

Title: Updating wxWidgets project wizard
Post by: PB on May 21, 2021, 06:15:41 pm
I have updated wxWidgets project wizard, with the main aim being to improve user experience on MS Windows with GCC.

Here is what I did:

Remove support for obsolete wxWidgets versions 2.6 and 2.8.

Improve linking on MSW:
* Allow linking with libraries introduced in wxWidgets 2.9: PropertyGrid, Ribbon, STC, and WebView.
* Allow linking with OpenGL for the monolithic build too.
* Do not offer to link with the 3rd party libraries (image formats, expat, regex, scintilla, zip), they are not needed for the DLL build and required for the static build.
* Allow linking with Winsock2 instead of Winsock.

By default, assume Unicode will be used and the generated application will be GUI instead of console one.

Make more options persistent and other minor improvements.


I believe the above improves the wizard and I am not aware of any real drawbacks. I have noticed that GitHub has a mirror code repository, which accepts PRs, so I submitted it there: https://github.com/obfuscated/codeblocks_sf/pull/21


There is certainly a room for further improvement and code cleanup. I was also itching to remove support for the ancient Open Watcom and Borland compilers (as I doubt these are supported by modern wxWidgets), but I let that be (for now?).


If anyone is interested in discussing the changes or, hopefully merging the update to Code::Blocks, I would gladly hear them out.

Title: Re: Updating wxWidgets project wizard
Post by: stahta01 on May 22, 2021, 12:19:25 am
PB: I wish you luck in getting at least some of the wxWidgets Wizard changes applied; I gave up on getting any of my changes applied a few years back.

Tim S.
Title: Re: Updating wxWidgets project wizard
Post by: oBFusCATed on May 22, 2021, 10:06:14 am
I've posted some comments.
Title: Re: Updating wxWidgets project wizard
Post by: PB on May 23, 2021, 01:05:27 pm
I have addressed all the comments in the PR and will wait for further input.

One of the questions asked there was: GCC on Windows may not be the best, what about clang?

I have no experience with clang but I installed MSYS2 package mingw-w64-x86_64-clang and built wxWidgets with it, using the mingw makefile. When trying to run the wizard with clang, there were errors, as function OnLeave_WxConf() (https://github.com/obfuscated/codeblocks_sf/blob/master/src/plugins/scriptedwizard/resources/wxwidgets/wizard.script#L304) does not test for clang. After hacking it, i.e., making the same settings for clang as for GCC, the wizard successfully finishes.

However, it seems that clang used as gcc cannot compile the windows resource:
Quote
windres.exe -ID:\Dev\Desktop\!Lib\wxWidgets-GIT\include -ID:\Dev\Desktop\!Lib\wxWidgets-GIT\lib\gcc_dll_clang\mswud  -J rc -O coff -i C:\dev\cb-tests\TEST-C~2\resource.rc -o obj\Debug\resource.res
clang++.exe -LD:\Dev\Desktop\!Lib\wxWidgets-GIT\lib\gcc_dll_clang -o bin\Debug\test-clang10s.exe  obj\Debug\test_clang10sApp.o obj\Debug\test_clang10sMain.o obj\Debug\resource.res  -lwxmsw31ud_webview -lwxmsw31ud_stc -lwxmsw31ud_propgrid -lwxmsw31ud_ribbon -lwxmsw31ud_richtext -lwxmsw31ud_xrc -lwxmsw31ud_aui -lwxmsw31ud_media -lwxbase31ud_net -lwxmsw31ud_gl -lwxmsw31ud_qa -lwxbase31ud_xml -lwxmsw31ud_adv -lwxmsw31ud_html -lwxmsw31ud_core -lwxbase31ud -Wl,--subsystem,windows
llvm-rc: Error in 24 statement (ID 1):
Is a directory
windres: error: llvm-rc failed

The same error was there when I tried to build a wxWidgets sample using GCC makefile too, so it is not a C::B issue.

To conclude, I think clang may not be usable with this wizard, modified or original.

BTW, it seems that clang debugger uses a different interface than GDB, is this supported by C::B?
Title: Re: Updating wxWidgets project wizard
Post by: oBFusCATed on May 23, 2021, 02:50:22 pm
The main question concerning the wizard is if checking for gcc derived compiler matches clang. If it doesn't then all is good. :)

BTW, it seems that clang debugger uses a different interface than GDB, is this supported by C::B?
Not yet.

p.s. how do you build wx? Just set CC and CXX env variables?
p.p.s. why are you using mingw-clang, when there is a official clang release?
Title: Re: Updating wxWidgets project wizard
Post by: oBFusCATed on May 23, 2021, 02:51:11 pm
People using the wizard, please check if it still works for your use cases. It should be possible to just test it on an older builds.
Title: Re: Updating wxWidgets project wizard
Post by: PB on May 23, 2021, 04:43:16 pm
The main question concerning the wizard is if checking for gcc derived compiler matches clang. If it doesn't then all is good. :)
Well, I would prefer if the wizard reported unsupported compiler and refused to continue, instead of failing with internal error. But perhaps it works on other platforms besides MSW?

how do you build wx? Just set CC and CXX env variables?

Exactly the same as with GCC, basically something like
Quote
PATH=C:\msys64\clang64\bin;%PATH%
cd %WXWIN%\build\MSW
mingw32-make -f makefile.gcc

why are you using mingw-clang, when there is a official clang release?
I know nothing about clang, using MSYS package seemed to be the simplest and safest way to get the whole working package (all compiler tools, headers, libraries...).
Title: Re: Updating wxWidgets project wizard
Post by: stahta01 on May 24, 2021, 09:58:13 am
FYI: MSYS2 instead of MSYS.

Tim S.
Title: Re: Updating wxWidgets project wizard
Post by: PB on June 01, 2021, 07:19:03 pm
I wanted to add autodetection of wxWidgets version on MSW. Letting the user select it is not only useless but having a predefined version list is also not future-proof.

My idea was looking for a wxWidgets mandatory library in OnLeave_WxConf(), by finding the library file and parsing the library file name.

E.g. in multilib the file to look for would be
Code
LibPrefix + _T("wxbase") + _T("??") + LibUnicSuffix + _T("?") + LibSuffix;
where I could then extract the version (e.g., "31") from where the two question marks are.

However the IO scripting API does not have a function working with wild cards, e.g. something like wxDir::FindFirst().

I would rather not do something like parse output of dir obtained via ExecuteAndGetOutput(). Any ideas?
Title: Re: Updating wxWidgets project wizard
Post by: AndrewCot on June 02, 2021, 01:33:41 am
This may be off topic, but be aware on Windows the three main GCC compilers collections/systems are:
1) MSYS2
2) MingW64
3) Cygwin

The MSYS2 and Mingw64 when you start to use them are different and if you try to mix the libraries causes issues. If you do install them on the one PC then based on my experience they will interfere with one another due to search path issues, so I rename the directories when swapping between the three.

Title: Re: Updating wxWidgets project wizard
Post by: ollydbg on June 02, 2021, 06:18:34 am
eranif/wx-config-msys2: wx-config tool for MSYS2 based installation of wxWidgets using the mingw64 repository (https://github.com/eranif/wx-config-msys2)
I recently found this good tool, and Code::Blocks support shell escape in the include search or lib search options, so using this could be simple. I haven't tried this tool yet.
Title: Re: Updating wxWidgets project wizard
Post by: PB on June 03, 2021, 10:44:30 am
This may be off topic, but be aware on Windows the three main GCC compilers collections/systems are:
1) MSYS2
2) MingW64
3) Cygwin

The MSYS2 and Mingw64 when you start to use them are different and if you try to mix the libraries causes issues. If you do install them on the one PC then based on my experience they will interfere with one another due to search path issues, so I rename the directories when swapping between the three.

I must have at least 10 GCC-based compiler toolchains installed, from three different "distributions" (mingw-w64, MSYS2, TDM). I have never encountered any issue but of course, I did not add any of them to the PATH.
Title: Re: Updating wxWidgets project wizard
Post by: PB on June 03, 2021, 10:57:05 am
eranif/wx-config-msys2: wx-config tool for MSYS2 based installation of wxWidgets using the mingw64 repository (https://github.com/eranif/wx-config-msys2)
I recently found this good tool, and Code::Blocks support shell escape in the include search or lib search options, so using this could be simple. I haven't tried this tool yet.

Sorry, I do not understand the relevance.

The wizard supports the following compilers: Open Watcom, Borland C++, MSVC, and GCC. IMO OW and BCC are dead and I do not think MSVC is used much with C::B.

Still, MSYS2 is but one GCC-based MSW distribution. wxWidgets developers suggest that on MSW, you should build wxWidgets by yourself which allows you also to tailor the build to your needs.

Please notice that when using MSYS2 prebuilt package:
1) The library file (and folder?) names are different than those of official wxWidgets binaries or the binaries self-built with GCC makefile (and in future CMake file).
2) AFAIK, the MSYS2 package does not contain the new Edge-based wxWebView, leaving you with the obsolete IE-based one. AFAICT, configure does not even support Edge backend.
3) Of course, you are at mercy of packagers, which wxWidgets versions do they offer and with which options (e.g., for some reason, some people seem to favour the monolithic build).

Do you really want the wizard to be tied to one wxWidgets distribution and being incompatible with self-built and official binaries?
Title: Re: Updating wxWidgets project wizard
Post by: ollydbg on June 03, 2021, 12:20:08 pm
Do you really want the wizard to be tied to one wxWidgets distribution and being incompatible with self-built and official binaries?
No, I think by using eranif/wx-config-msys2 tool, config wx project may be simple. I mean I can only create a simple console project, and tweak the include search path, lib search path and libs by using the shell escape command.

The expect way could let our wxWidgets wizard also support msys2's prebuild libraries.
Title: Re: Updating wxWidgets project wizard
Post by: cacb on June 03, 2021, 05:44:14 pm
The wizard supports the following compilers: Open Watcom, Borland C++, MSVC, and GCC. IMO OW and BCC are dead and I do not think MSVC is used much with C::B.

It may be that MSVC is not very common with C::B, but I have used that combination for many years and still do.
Title: Re: Updating wxWidgets project wizard
Post by: PB on June 03, 2021, 09:21:11 pm
No, I think by using eranif/wx-config-msys2 tool, config wx project may be simple. I mean I can only create a simple console project, and tweak the include search path, lib search path and libs by using the shell escape command.
The expect way could let our wxWidgets wizard also support msys2's prebuild libraries.

Sorry, I still do not understand. Are you proposing for the wizard to somehow have a special code path for MSYS2 wxWidgets package, different from all other compilers? How would it look concretely?
Title: Re: Updating wxWidgets project wizard
Post by: stahta01 on June 03, 2021, 11:43:06 pm
No, I think by using eranif/wx-config-msys2 tool, config wx project may be simple. I mean I can only create a simple console project, and tweak the include search path, lib search path and libs by using the shell escape command.
The expect way could let our wxWidgets wizard also support msys2's prebuild libraries.

Sorry, I still do not understand. Are you proposing for the wizard to somehow have a special code path for MSYS2 wxWidgets package, different from all other compilers? How would it look concretely?

I think he is saying that he is going to try using the wx-config-msys2 tool and seeing if the unix code style CB project will work.

Tim S.
Title: Re: Updating wxWidgets project wizard
Post by: PB on June 04, 2021, 09:50:04 pm
Using some external executable or using MSYS2 package is way over my head, so I will not be doing that even if it may be similar to what is done in SetupProject() in ChoiceWxUnixLib-related statements. Sorry.
Title: Re: Updating wxWidgets project wizard
Post by: PB on June 21, 2021, 04:41:48 pm
I was thinking about this some more.

Currently on MSW the wizard expects wxWidgets to be built-in source, having both debug and release libraries in the same folder, and library names matching those from makefile build, i.e., the old MSW idiom.

However, there are two possible out-of-the source build options: (1) CMake and (2) configure.

Therefore the wizard should not ask only for a single folder but for include folder as well as for the library folders, allowing for release and debug build to be in different folders. It should also support both library naming patterns.

However, I am not sure how to fit this in the existing wizard and if it is even possible implement with the scripting API.
Title: Re: Updating wxWidgets project wizard
Post by: oBFusCATed on June 21, 2021, 05:22:13 pm
However, I am not sure how to fit this in the existing wizard and if it is even possible implement with the scripting API.
Why do you think it is not possible? You want to do the detection automatically?
Title: Re: Updating wxWidgets project wizard
Post by: PB on June 21, 2021, 06:52:20 pm
I will have to think about it some more (and perhaps try writing code), I should have more time to do that at the beginning of July.

Obviously, the wizard should be as easy to use but also as versatile as possible. These two may not go hand in hand.

I am afraid that in order to support all kinds of builds (e.g., makefile, cmake, configure...), the wizard will have to ask the user which kind of build to use. Based on the choice, the user will be asked about the wxWidgets folders locations (include, libraries).

However, I am not sure how to fit this in the existing wizard and if it is even possible implement with the scripting API.
Why do you think it is not possible? You want to do the detection automatically?
I would like at least obtaining wxWidgets version be automatic, if nothing else to attempt some future-proofing. As I wrote before, I believe the scripting API lacks a function such as wxDir::FindFirst() which finds a file based on a wild card match.  Such function can be used to get wxWidgets version but also to detect library naming pattern or whether the build is static/dynamic, monolithic/multilib...

BTW, are there easy-to-follow and up-to-date instructions on how to build Code::Blocks on Windows? I did try to find them back when I started messing with the wizard but could not find any.
Title: Re: Updating wxWidgets project wizard
Post by: Miguel Gimenez on June 21, 2021, 07:22:37 pm
The wiki (https://wiki.codeblocks.org/index.php/Installing_Code::Blocks_from_source_on_Windows) is reasonably up to date.

I suppose you already have wxWidgets compiled, but C::B needs a monolithic build with wxUSE_GRAPHICS_DIRECT2D=1 (this is explained in the llink)
Title: Re: Updating wxWidgets project wizard
Post by: PB on June 21, 2021, 07:27:54 pm
The wiki (https://wiki.codeblocks.org/index.php/Installing_Code::Blocks_from_source_on_Windows) is reasonably up to date.

I suppose you already have wxWidgets compiled, but C::B needs a monolithic build with wxUSE_GRAPHICS_DIRECT2D=1 (this is explained in the llink)

IIRC, I failed in C::B when it asked about some folders (or system variables?), something like CB_DEVEL where I had no idea where to set them. But it also may be related to some 3rd party library (tinyXML?).

I will try again and will ask if I run into an issue.
Title: Re: Updating wxWidgets project wizard
Post by: oBFusCATed on June 21, 2021, 07:29:59 pm
cb_release_type... set it to -O0 -g if you want to save yourself recompiling when you need to debug something.

Generally I want to finish this pull request and commit what we have at the moment. Additional changes could be committed later as a second step.
Are people interested in wx on windows able to test this PR and report if the wizard works for them?
Title: Re: Updating wxWidgets project wizard
Post by: PB on June 21, 2021, 07:42:36 pm
Generally I want to finish this pull request and commit what we have at the moment. Additional changes could be committed later as a second step.

I agree with this with perhaps one suggestion based on the discussion here or in the PR.

Currently, the wizard presets the wxWidgets location to "$(#wx)". Perhaps it would be better to firstly check if a variable based on selected wxWidgets version (e.g. "$(#wx30)" for 3.0 and "$(#wx31)" for 3.1) exists and if it does use that. If it does not fall back to "$(#wx)". What do you think about this?
Title: Re: Updating wxWidgets project wizard
Post by: oBFusCATed on June 22, 2021, 02:41:00 am
Currently, the wizard presets the wxWidgets location to "$(#wx)". Perhaps it would be better to firstly check if a variable based on selected wxWidgets version (e.g. "$(#wx30)" for 3.0 and "$(#wx31)" for 3.1) exists and if it does use that. If it does not fall back to "$(#wx)". What do you think about this?
This would be useful for people which switch wx versions often or want to test them easily. I'm not sure this is generally useful. And as far as I know it is possible to change it in the wizard if you're in this kind of situation. So for now I think it is better that we don't add this feature.
Title: Re: Updating wxWidgets project wizard
Post by: AndrewCot on June 24, 2021, 09:25:27 am
While the wxwidget project wizard is being reworked then ticket 511 is relevant as it includes wizard patches that were never merged and there is no reason or comments or feedback in the ticket.

It may be worth looking at the ticket to see if the changes are relevant and if they are to see if the changes already incorporate the changes or not and if not then if they shoudl eb included in the work then or if eventually the changes are deemed to not be required then see about closing the ticket.
Title: Re: Updating wxWidgets project wizard
Post by: PB on June 25, 2021, 10:32:09 pm
While the wxwidget project wizard is being reworked then ticket 511 is relevant as it includes wizard patches that were never merged and there is no reason or comments or feedback in the ticket.


AFAICT, the code in the ticket adds a button allowing to display the global variables dialog, in the place where a path can be already selected.

Hence, this has no effect on my proposed changes in the wxWidgets wizard script.
Title: Re: Updating wxWidgets project wizard
Post by: oBFusCATed on June 29, 2021, 12:21:38 am
While the wxwidget project wizard is being reworked then ticket 511 is relevant as it includes wizard patches that were never merged and there is no reason or comments or feedback in the ticket.
511 is not relevant here. Also there is pretty elaborate and detailed technical discussion in the ticket. I've raised some concerns which haven't been addressed, so it is up to bluehazzard to decide what to do with this ticket.
Title: Re: Updating wxWidgets project wizard
Post by: oBFusCATed on June 29, 2021, 05:23:12 pm
Latest changes about this are here: https://github.com/obfuscated/codeblocks_sf/tree/experiments/wxwidgets_wizard
Please test and report if there are problems not present in trunk/master.