Build CodeBlocks using Microsoft Visual C++

[xunxun]

@loaden
it seems you add a lot of DLLIMPORT before the class declaration. But why they are not needed when build with MinGW GCC?

Because MinGW GCC export  all symbols defaultly.

[Loaden]

@loaden
You patches v6 contains a lot of duplicated piece code. (which means: you don't change anything on the code, maybe, there are some space, tabs added/moved)

Sure, I am re-make the patch now.

[attachment deleted by admin]

[oBFusCATed]

Simple question: have you tried to compile C::B with gcc on windows and linux with your patch applied, I think you will have problems
Also why is that "" to _T("") needed all over the place?

I don't think so, Only need a little guard code (like #ifdef _MSC_VER), and seems very clearly.

Hm, your patch is 120+ KB, so the changes aren't minimal

Also:
1. Have you tried to use something different from vc 2010?
2. Don't compile add C++ features to C files (VC always compiles .c files as C++ and you should tell it to compile it as C with some compiler flag) (I'm talking about the files in depslib)
3. Don't call that start with _ they are MS only most of the time
4. When there is a missing function, you should reimplement it, not add #ifdef #else #endif guards

[Loaden]

Simple question: have you tried to compile C::B with gcc on windows and linux with your patch applied, I think you will have problems

I am *only* test it using GCC 4.4.4 on Windows 7 SP1 / XPSP3, and it's works well.

I don't think so, Only need a little guard code (like #ifdef _MSC_VER), and seems very clearly.

Hm, your patch is 120+ KB, so the changes aren't minimal

Most of them are Multi-line String fixed.
e.g.
Change from:
_("aaa"
   "bbb")
TO:
_("aaa"
   _T("bbb"))

Also:
1. Have you tried to use something different from vc 2010?
2. Don't compile add C++ features to C files (VC always compiles .c files as C++ and you should tell it to compile it as C with some compiler flag) (I'm talking about the files in depslib)
3. Don't call that start with _ they are MS only most of the time
4. When there is a missing function, you should reimplement it, not add #ifdef #else #endif guards

1. No
2. I am using /TP flags, Why not? What is the reason?
3. Revert the changes in V8 patch
4. Only two case:
   (1)
   #ifndef _MSC_VER // TODO (Loaden#5#) error C2017: illegal escape sequence
        Quoted.Replace(wxString(_T("‘")), _T("\""), true);
        Quoted.Replace(_T("’"), _T("\""), true);
   #endif
   (2)
   #ifndef _MSC_VER // TODO (Loaden#1#) MSVC can't support gettimeofday
   #include <sys/time.h>
   #endif

Many thanks for feedback!!

[ollydbg]

Hey, loaden, unpack the 23K 7zip file, the patch is still 131K, Oh my God.

But, I review the patch, it does change only a little code.

[Loaden]

BTW: V8 patch can be compiled in two modes, Debug or Release, But it can't work, when startup, CB will crash.
Here is the V8 project.

[Loaden]

Hey, loaden, unpack the 23K 7zip file, the patch is still 131K, Oh my God.

But, I review the patch, it does change only a little code.

The most important is that it's without any side effects when compile CB based on GCC compiler.
Able to compile at least have taken the first step!
But currently the CB of compiled with MSVC does not work.
Welcome to test and improve!

As I know, QtCreator use the VC compiler to release the binary.
 

[MortenMacFly]

I personally believe targeting MSVC compilation is a waste of time, really, as this not requested and needed at all. And I doubt that there will be a speed improvement. Looking at the patch I see it brings back the clutter we had just removed. And having this patch applied I can no longer compile C::B using MinGW/GCC... so what's the purpose? :shock:

More important, however, is to improve the support for the MSVC compiler inside C::B. MSVC10 is still not 100% supported (I am working on that).

Also (if you are looking for some work to do ;-)) CC freezes C::B completely if you do a massive search-and-replace in many files across a large (C::B) workspace with multiple projects. This is truly annoying.

[Loaden]

My Linux OS can not startup now.
Could someone help test V8 patch on Unix?
Thanks!

[Loaden]

Also (if you are looking for some work to do ;-)) CC freezes C::B completely if you do a massive search-and-replace in many files across a large (C::B) workspace with multiple projects. This is truly annoying.

That's is a reason to support MSVC.
Because I need MSVC's Debug Tools (or WinDbg), and I need create a dump file use dbghelp.dll.
In CC, there has a crash, But use GDB, I can't catch it!

[oBFusCATed]

Why do you think cdb/windbg is better in this?
Why don't you install linux and then use valgrind to see if you're not doing something wrong with the memory?

[MortenMacFly]

Why do you think cdb/windbg is better in this?

I think what Loaden means is not the debugger, but the debugger integrated in the IDE. So the target is o be able to use the MSVC IDE to debug C::B. This (in fact) might be more comfortable than C::B (although I ma very happy with C::B).

@Loaden: Did you try to connect/debug C::B using gdb from another C::B instance? This way you can debug thread issues for example...

[Jenna]

I can not apply the patch on linux. Too many errors (possible a line-ending problem).

[MortenMacFly]

Change from:
_("aaa"
   "bbb")
TO:
_("aaa"
_T("bbb"))

BTW: This will break translations IMHO, as the second part (now _T("")) will not appear in the translation tables. You should always use _("").

[ollydbg]

Also (if you are looking for some work to do ;-)) CC freezes C::B completely if you do a massive search-and-replace in many files across a large (C::B) workspace with multiple projects. This is truly annoying.

Oh, catching bugs was quite interesting and challenge for me  , but I can't find some annoying bug in CC. (though some parsing errors due to the fact that CC's parser was not a full compiler parser).
Did you use the debugged version of c::b (maybe, run under gdb) to catch some information?