I've finally managed to compile C::B using VC 2003 Toolkit (actually, I used VisualStudio 2003) in Unicode. Now it can be debugged using a superb VisualStudio debugger :)
During this process I've fixed numerous incompatibilities. Here are the major ones:
- 1. VC's preprocessor doesn't support variable number of parameters in macroses. So I had to correct CFG_READ and CFG_WRITE.
- 2. VC's preprocessor doesn't understand such constructs:
SomeFunc(_("Text, text, text"
"text continues"
"end of text"));
It rewrote all such occurrences to:
SomeFunc(_("Text, text, text"
_T("text continues")
_T("end of text")));
[li]3. I've added correct class exports, so SDK can now be built as a DLL with VC.[/li]
[/list]
You can download patched codeblocks from: http://scb.udsu.ru/~cyberax/codeblocks_vc.zip
Thanks for the effort.
Where's that patch again? ;)
For #2, are you sure they are equivalent?
Also, you sure
SomeFunc(_("Text, text, text" \
"text continues" \
"end of text"));
doesn't work?
Also it would be good if you could come up with some write up to build c::b using Visual Studio.
I am also facing problems while debugging c::b using gdb on windows. i am not able to debug plugins, even after following the suggested method of putting a breakpoint in ScanforPlugins and then by adding the symbol file.
Thanks
Sanjiv
Quote from: grv575 on September 25, 2005, 08:45:19 PM
For #2, are you sure they are equivalent?
Yes, I am sure.
Quote
Also, you sure
SomeFunc(_("Text, text, text" \
"text continues" \
"end of text"));
doesn't work?
Yes. In Unicode mode '_("Text")' is exapanded to 'L"Text"', so this code will look like:
Quote
SomeFunc(L"Text, text, text" \
"text continues" \
"end of text");
This is not a Standard-compliant code and VC7.1 will not compile it ("error C2308: concatenating mismatched wide strings").
Just for reference, ISO/IEC 14882:2003(E) 2.13.4.3:
Quote
If a narrow string literal token is adjacent to a wide string literal token, the behavior is
undefined.
Quote from: sanjivg on September 26, 2005, 10:04:54 AM
Also it would be good if you could come up with some write up to build c::b using Visual Studio.
I am also facing problems while debugging c::b using gdb on windows. i am not able to debug plugins, even after following the suggested method of putting a breakpoint in ScanforPlugins and then by adding the symbol file.
There's no need to build C::B using VisualStudio, you can export makefile from C::B and build it using VS's "Makefile project". I'm going to add this to wiki as soon as I have some spare time.
Quote from: Cyberax on September 25, 2005, 04:37:28 PM
I've finally managed to compile C::B using VC 2003 Toolkit (actually, I used VisualStudio 2003) in Unicode. Now it can be debugged using a superb VisualStudio debugger :)
...
You can download patched codeblocks from: http://scb.udsu.ru/~cyberax/codeblocks_vc.zip
Hello Cyberaxe
i downloaded your patch but i couldn't find any of the necessary project files to build it with VS2003.
Can you please supply these along with a short description how to build the codeblocks project with VS ?
thanks
cd <WXWIN>\build\msw
nmake -f makefile.vc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=debug UNICODE=1 VENDOR=cb clean
nmake -f makefile.vc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=debug UNICODE=1 VENDOR=cb
[li]2. Open CodeBlocks-wx-vc.cbp with C::B and compile it.[/li]
[/list]
NOTE: C::B and wxWidgets will be compiled in debug mode (VC can't mix debug and release code well enough).
Quote from: Cyberax on September 26, 2005, 02:44:50 PM
...
2. Open CodeBlocks-wx-vc.cbp with C::B and compile it
thanks, :shock: didn't see the wood for the trees
Oh, it's just "abc" "cde";
So
SomeFunc(_("Text, text, text \
text continues \
end of text"));
gives extra whitespace or no? (forget)
Anycase I didn't realize it was just standard concatenation.
Quote from: grv575 on September 27, 2005, 03:31:24 AM
SomeFunc(_("Text, text, text \
text continues \
end of text"));
gives extra whitespace or no? (forget)
Yes, it does.
Anyway, the Right Thing (tm) to do is using resource bundles. Maybe someone should bite the bullet and extract all text strings to resource files?
Quote from: Cyberax on September 26, 2005, 02:44:50 PM
- 1. Compile wxWidgets:
- 2. Open CodeBlocks-wx-vc.cbp with C::B and compile it.
NOTE: C::B and wxWidgets will be compiled in debug mode ...
Hi Cyberax
now i've build C::B with VisualStudio2003 (VC7.1)
using your project file adapted for wxMSW2.6.1_ansi_debug_dll
with the unicode version i couldn't open a single file !
well, the result
isn't exciting till now.
It compiles with 124 warnings and works with a number of flaws (but no crash till now) and runs terribly slow !
There is a lot of work to do until we have a M$-VS port of C::B, but a start is made ...
thanks again for your input, Cyberax.
Quote from: tiwag on September 27, 2005, 02:58:12 PM
now i've build C::B with VisualStudio2003 (VC7.1)
using your project file adapted for wxMSW2.6.1_ansi_debug_dll
with the unicode version i couldn't open a single file !
It's strange, Unicode version of C::B worked fine for me. I was able to compile C::B from it.
Quote
well, the result isn't exciting till now.
I know :(
Quote
It compiles with 124 warnings and works with a number of flaws (but no crash till now) and runs terribly slow !
There is a lot of work to do until we have a M$-VS port of C::B, but a start is made ...
I've fixed some warnings in my working copy. I was also able to compile a release version of C::B (and it runs very fast), but it crashed during compilation.
I'd greatly appreciate project admins giving me a write access in CVS (in a branch or a separate directory), so I can share my bugfixes.
Quote from: Cyberax
...
I've fixed some warnings in my working copy.
I was also able to compile a release version of C::B (and it runs very fast), but it crashed during compilation.
There is something bad with event handling - the speed-difference between debug and release versions can't be that big. My build consumes up to 95% of cpu-power just when moving the mouse around the C::B-window ! The menus react with 0.5 to 2 sec. delay ! terrible slow !
Quote from: Cyberax
I'd greatly appreciate project admins giving me a write access in CVS (in a branch or a separate directory), so I can share my bugfixes.
you can make patch-files, zip them, then rename the extension .zip to .txt and post the files here in this thread.
Quote from: tiwag on September 27, 2005, 05:14:22 PM
Quote from: Cyberax
There is something bad with event handling - the speed-difference between debug and release versions can't be that big. My build consumes up to 95% of cpu-power just when moving the mouse around the C::B-window ! The menus react with 0.5 to 2 sec. delay ! terrible slow !
Can you check your debugger log? If C::B constantly writes messages there, it can easily slow everything by the factor of 10.
Quote from: tiwag on September 27, 2005, 05:14:22 PM
Quote from: Cyberax
I'd greatly appreciate project admins giving me a write access in CVS (in a branch or a separate directory), so I can share my bugfixes.
you can make patch-files, zip them, then rename the extension .zip to .txt and post the files here in this thread.
I'm going to setup a private SVN repository (with anonymous read-only access) and sync it with the main C::B repository using SVK (http://svk.elixus.org/).
Quote from: Cyberax
Can you check your debugger log? If C::B constantly writes messages there, it can easily slow everything by the factor of 10.
checked this ... nothing is being written to the debugger log window ...
Quote from: Cyberax
I'm going to setup a private SVN repository (with anonymous read-only access) and sync it with the main C::B repository using SVK (http://svk.elixus.org/).
aaaargh ... WinCVS, TortoiseCVS, SVN, VCS and now SVK, what else do we need ? do we need them really ? couldn't we stay with ordinary cvs ?