Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
2
Development / Re: RFC: Backticks
« Last post by ollydbg on Today at 05:50:56 am »
You don't need them there. wx-config works fine on linux as it is now.

The good news is that eranif's wx-config-msys2 tool also works well with our C::B's backtick system.

I try to add those lines in the "Other linker options"
Code
`wx-config-msys2 --libs --prefix=$(TARGET_COMPILER_DIR)`

And I got the final result of the linke command:

Code
-LF:\code\msys2-64\mingw64\\lib -pipe -Wl,--subsystem,windows -mwindows -lwx_mswu_xrc-3.1 -lwx_mswu_html-3.1 -lwx_mswu_qa-3.1 -lwx_mswu_core-3.1 -lwx_baseu_xml-3.1 -lwx_baseu_net-3.1 -lwx_baseu-3.1

The only issue is that for C::B, we have $(TARGET_COMPILER_DIR) translated to "F:\code\msys2-64\mingw64\", while, wx-config-msys2 expect there is no ending backslash for the path, so you see double backslashes in the generated command line.
3
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by oBFusCATed on Today at 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.
4
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by PB on Yesterday at 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?
5
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by oBFusCATed on Yesterday at 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?
6
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by PB on Yesterday at 07:27:54 pm »
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.
7
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by Miguel Gimenez on Yesterday at 07:22:37 pm »
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)
8
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by PB on Yesterday at 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.
9
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by oBFusCATed on Yesterday at 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?
10
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by PB on Yesterday at 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.
Pages: [1] 2 3 4 5 6 ... 10