Author Topic: Build CodeBlocks using Microsoft Visual C++  (Read 39075 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Build CodeBlocks using Microsoft Visual C++
« Reply #45 on: April 07, 2011, 10:29:12 am »
Because you've not build it correctly, most probably :)
Or someone has done something non portable.

BTW: I'm for enabling multiple compilers, because this makes the code more robust and more portable (even with the mad vc++)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Build CodeBlocks using Microsoft Visual C++
« Reply #46 on: April 07, 2011, 11:10:15 am »
If the direction is not to include such patches to trunk then it is not necessary to create a branch and then abandon it later. I'd rather keep my local copy in sync and dump the whole patched source somewhere in the web. :)
I didn't mean to abandon. Its easy to keep the branch in sync with trunk. We did this so often in the past and have two active branches that do so just fine. It's an experiment in the end, needed for a special purpose from time-to-time. The main stream development has to be in MinGW/GCC.

So, whenever you need the branch make it in sync with trunk and use it. These are 3 mouse clicks in my SVN software. And once stabilised you wouldn't even cause conflicts as there won't be much changes. And if we come to design guidelines (e.g. never do something like:
Code
_("text....\n"
   "more text...")
)
...which we apply in trunk the differences will be minimised.

If we have too many branches I believe we will end up in merge conflict while keeping them in sync. And we also need somebody to maintain it. Using #ifdef is much easier than than doing a merge every now & then and most importantly it will not touch officially supported code. Anyway it's a personal preference.

Why do you believe it would be better to
dump the whole patched source somewhere in the web. :)
then??? It will make it way harder to handle.

Interested ones can retrieve it easily. If we don't care about VC compatibility then officially there is no need to manage it. 
Be a part of the solution, not a part of the problem.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5491
Re: Build CodeBlocks using Microsoft Visual C++
« Reply #47 on: April 07, 2011, 11:36:24 am »
I also favor to be able to run the code with different compilers. But I think we should intend to write as much portable code as possible. The platform dependencies and non portable parts for us should be in the wxwidgets parts.

One place that already comes to mind where to nasty ifdefs will be needed is the declspec shit in order to export/import shared libraries.

That is basically ifdef else ... to define in the end one macro, and then we put that macro in front of the classes/functions we want to export.
That mumbo jumbo ifdef else could be put in a dedicated header in order not to repeat this all the time in every class who wants to export stuff.
I guess this already kind of occurs in sdk.h (should check).

Hmmmmmm, just realized we should already have this since MinGW is also doing this stuff, dunno if gcc uses the same syntax on windows and linux ?

Could maybe someone list other potential changes (so not just giving a patch), a nice list. That way we can nicely investigate/debate on the gain we get or the price we have to pay.

But I assume in 99% of the code we shouldn't do anything, code should be as portable as possible (as said wxwidgets is the one doing the dirty portability work for us).


Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: Build CodeBlocks using Microsoft Visual C++
« Reply #48 on: April 29, 2011, 05:36:23 am »
EDIT: fix build error
V12: Change to ANSI build (Compatible with xgettext)
Quote
nmake -f makefile.vc CPPFLAGS=/Os LDFLAGS="/MANIFEST:NO /OPT:REF /OPT:ICF" BUILD=debug SHARED=1 UNICODE=0 DEBUG_INFO=0 DEBUG_FLAG=1 MONOLITHIC=1 OFFICIAL_BUILD=1
nmake -f makefile.vc CPPFLAGS=/Os LDFLAGS="/MANIFEST:NO /OPT:REF /OPT:ICF" BUILD=release SHARED=1 UNICODE=0 DEBUG_INFO=0 DEBUG_FLAG=0 MONOLITHIC=1 OFFICIAL_BUILD=1
And I catch the crash using Visual Studio Debugger.
Quote
>   CodeBlocks.exe!sq_getprintfunc(SQVM * v)  Line 1255 + 0x3 bytes   C++
    CodeBlocks.exe!ScriptConsole::ScriptConsole(wxWindow * parent, int id)  Line 116 + 0xb bytes   C++
    CodeBlocks.exe!MainFrame::CreateIDE()  Line 701 + 0x37 bytes   C++
    CodeBlocks.exe!MainFrame::MainFrame(wxWindow * parent)  Line 553   C++
    CodeBlocks.exe!CodeBlocksApp::InitFrame()  Line 405 + 0x27 bytes   C++
    CodeBlocks.exe!CodeBlocksApp::OnInit()  Line 639 + 0xb bytes   C++
    wxmsw28d.dll!65e81ea7()    
    [Frames below may be incorrect and/or missing, no symbols loaded for wxmsw28d.dll]   
    wxmsw28d.dll!65ec6bcb()    
    MSVCR100D.dll!_getptd_noexit()  Line 500   C
    0018fb54()   
It's seems the crash occured in Squirrel.
Any comment are welcome!
« Last Edit: April 29, 2011, 08:49:33 am by Loaden »