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
BTW, it seems that clang debugger uses a different interface than GDB, is this supported by C::B?Not yet.
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?
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...).
LibPrefix + _T("wxbase") + _T("??") + LibUnicSuffix + _T("?") + LibSuffix;
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.
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.
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 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.
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.
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?
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...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?
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)
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.
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.
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.
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.