Updating wxWidgets project wizard

[PB]

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?

[stahta01]

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.

[PB]

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.

[PB]

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.

[oBFusCATed]

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?

[PB]

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.

[Miguel Gimenez]

The wiki 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)

[PB]

The wiki 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.

[oBFusCATed]

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?

[PB]

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?

[oBFusCATed]

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.

[AndrewCot]

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.

[PB]

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.

[oBFusCATed]

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.

[oBFusCATed]

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.