Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by PB on Today 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?
2
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by oBFusCATed on Today 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?
3
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by PB on Today 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.
4
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by Miguel Gimenez on Today 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)
5
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by PB on Today 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.
6
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by oBFusCATed on Today 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?
7
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by PB on Today 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.
8
Nightly builds / Re: The 20 June 2021 build (12462) is out.
« Last post by nenin on Today at 11:10:56 am »
I used this one: https://github.com/hyperrealm/libconfig/archive/refs/tags/v1.7.3.zip
I have no any minimal projects because I have no Visual Studio.
9
Nightly builds / Re: The 20 June 2021 build (12462) is out.
« Last post by oBFusCATed on Today at 10:45:04 am »
Can you share a minimal/example project which can be used to reproduce this?
10
Nightly builds / Re: The 20 June 2021 build (12462) is out.
« Last post by nenin on Today at 10:14:26 am »
C::B continue to throw similar dialogs in solid amount (few times for each target in solution), then finally import it. I can not say at that moment if this import is correct. 
In case of the <Cancel> I got RPT.
Pages: [1] 2 3 4 5 6 ... 10