Author Topic: Compiling Code::Blocks with the MS compiler  (Read 19309 times)

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Compiling Code::Blocks with the MS compiler
« on: January 22, 2006, 04:13:56 am »
The SVN version doesn't compile with it.

Is anyone even interested in support for this?
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

takeshimiya

  • Guest
Re: Compiling Code::Blocks with the MS compiler
« Reply #1 on: January 22, 2006, 04:33:19 am »
I'm really interested, but I've tried some time ago, and failed.

I really would like to see that C::B can be compiled with: MSVC, DMars, and Intel compilers.

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Compiling Code::Blocks with the MS compiler
« Reply #2 on: January 22, 2006, 05:29:51 am »
OK I got the core working and the AStyle plugin :)

Now I'm finishing up with the other main plugins.

It still builds fine in GCC with my changes... better, actually. :woot:
« Last Edit: January 22, 2006, 05:35:05 am by 280Z28 »
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Compiling Code::Blocks with the MS compiler
« Reply #3 on: January 22, 2006, 05:35:09 am »
280: Mind explaining what changes are you making so we can understand and maybe cooperate?
Have you tested that GCC doesn't get broken?


Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Compiling Code::Blocks with the MS compiler
« Reply #4 on: January 22, 2006, 05:52:17 am »
280: Mind explaining what changes are you making so we can understand and maybe cooperate?
Have you tested that GCC doesn't get broken?

Some of the changes are:

Strings:
Code
Old: _T("text" "moretext")
New: _T("text") _T("moretext")

Multiple inheritance (one example)
ProjectManager must derive from wxEvtHandler, THEN from Mgr<ProjectManager>:
Code
class WXDLLIMPEXP_CB ProjectManager : public wxEvtHandler, public Mgr<ProjectManager>

dllimport/dllexport... lots of changes to the way these were used and it works in GCC and MSVC now, and obviously won't change non-msw builds.

Fixed unchecked pointer errors, etc.

Fixed incorrectly declared and incorrectly used custom events



I prefer to just check them in if I could. That'd be much easier. :)
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

takeshimiya

  • Guest
Re: Compiling Code::Blocks with the MS compiler
« Reply #5 on: January 22, 2006, 06:02:06 am »
Fixed unchecked pointer errors, etc.

Fixed incorrectly declared and incorrectly used custom events

That demonstrates that compiling against more than one compiler is always good.  :)

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Compiling Code::Blocks with the MS compiler
« Reply #6 on: January 22, 2006, 06:22:23 am »
Whoever wrote depslib needs to be informed that in C, all variable declarations go at the beginning of their scope. Microsoft's compiler is rather strict about language rules. :)
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Compiling Code::Blocks with the MS compiler
« Reply #7 on: January 22, 2006, 06:49:13 am »
Quote from: 280Z28
Whoever wrote depslib needs to be informed that in C, all variable declarations go at the beginning of their scope. Microsoft's compiler is rather strict about language rules. :)

And somebody should tell Microsoft C99 is already out (right, since 1999) and it allows variable declarations just like in C++ ("mixed declarations and code" like the standard calls them), and many things more.

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Compiling Code::Blocks with the MS compiler
« Reply #8 on: January 22, 2006, 07:21:27 am »
Quote from: 280Z28
Whoever wrote depslib needs to be informed that in C, all variable declarations go at the beginning of their scope. Microsoft's compiler is rather strict about language rules. :)

And somebody should tell Microsoft C99 is already out (right, since 1999) and it allows variable declarations just like in C++ ("mixed declarations and code" like the standard calls them), and many things more.

I think they stopped that because people still writing C code in 2005 are doing it for portability and not for high level language features. Not really sure, but I know reordering the declaration fixed the build problems.
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Compiling Code::Blocks with the MS compiler
« Reply #9 on: January 22, 2006, 08:02:40 am »
Stopped what? Who? Features are there to implement and use. That's what I hate the most of MS: they give a *** about standards. You can forgive MS Visual C++ 6.0 for being that horrible for C++ 'cause it was released the same year of the first ISO standard for C++, but a recent version of the C compiler still using some kind of C89/C90? C'mon, it's 2006. I think they've had enough time, and obviously money, to implement that.

And add to that those "deprecated by MS" C functions in Visual C++ 2005. Those functions haven't been deprecated by the ISO, no reason for a compiler to throw warnings about!

BTW, portability in this case is highly related to following standards.

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Compiling Code::Blocks with the MS compiler
« Reply #10 on: January 22, 2006, 08:20:43 am »
The compiler with VS 2005 is one of the most compliant compilers available.

Functions were deprecated primarily for two reasons:

1) Known insecurities. Obvious reason to deprecate. If you don't feel like changing these, define the following directive:

#define _CRT_SECURE_NO_DEPRECATE

2) Non-standard items. Things that were never in the C++ standard to start with have been deprecated. Turn these off:

#define _CRT_NONSTDC_NO_DEPRECATE
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Compiling Code::Blocks with the MS compiler
« Reply #11 on: January 22, 2006, 09:57:30 am »
I got all the plugins from the main project working in it :)
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: Compiling Code::Blocks with the MS compiler
« Reply #12 on: January 22, 2006, 09:59:24 am »
always use more compilers to compile you code (if possible)
how about turning those c files into c++, so the c++ compiler treats them as c++ and not as c (in case of the same compiler), more over c is subset of c++ ??

[EDIT] It would indeeed by nice to have CB and plug-ins compilable with different compilers, but stick to the standards, so if we use C, don't screw it up for M$-s sake. Make C++ out of it, I know Thomas once wrote here a good reason, to have them as C, don't remember the argument anymore.
« Last Edit: January 22, 2006, 10:02:07 am by killerbot »

takeshimiya

  • Guest
Re: Compiling Code::Blocks with the MS compiler
« Reply #13 on: January 22, 2006, 12:18:04 pm »
I got all the plugins from the main project working in it :)

So that means it works everything just like with GCC?
I wonder if compiling with DMars would work. You know, having C::B to compile exactly 20 times faster than GCC is not something minor. :D

Offline Der Meister

  • Regular
  • ***
  • Posts: 307
Re: Compiling Code::Blocks with the MS compiler
« Reply #14 on: January 22, 2006, 01:10:34 pm »
I just compiled Code::Blocks revision 1828 with the Linux version of icc 9.0 and it seems to work well. Just a few changes were necessary:

First one for AngelScript:
Code
Index: src/sdk/as/source/as_scriptengine.cpp
===================================================================
--- src/sdk/as/source/as_scriptengine.cpp (revision 1828)
+++ src/sdk/as/source/as_scriptengine.cpp (working copy)
@@ -2236,7 +2236,7 @@
  }
  else if( i->callConv == ICC_STDCALL )
  {
- void (STDCALL *f)(void *, void *) = (void (STDCALL *)(void *, void *))(i->func);
+ void (STDCALL *f)(void *, void *) = (void (/*STDCALL*/ *)(void *, void *))(i->func);
  f(param1, param2);
  }
  else
I'm sure if this still works - but without this change icc produces weired error messages. Probably because it seems to behave as GCC and has __GNUC__ makros (or something similar) defined and STDCALL is therefore expandet to __attribute(stdcall) (or something similar) and icc doesn't undertand this.

The next patch is for keybinder:
Code
Index: src/plugins/contrib/keybinder/keybinder.cpp
===================================================================
--- src/plugins/contrib/keybinder/keybinder.cpp (revision 1828)
+++ src/plugins/contrib/keybinder/keybinder.cpp (working copy)
@@ -1421,7 +1421,7 @@
 
  // use a combobox + a listbox
  m_pCommandsList = new wxListBox(this, wxKEYBINDER_COMMANDS_BOX_ID, wxDefaultPosition,
- wxDefaultSize, 0, NULL);
+ wxDefaultSize, 0, 0);
  m_pCategories = new wxComboBox(this, wxKEYBINDER_CATEGORIES_ID,
  wxEmptyString, wxDefaultPosition, wxDefaultSize,
  0, NULL, wxCB_READONLY);

That's because in C++ 0 should be used instead of NULL for a zero-pointer. With NULL icc complains about two constructors that are matching to the current call.

And the last one is for the profiler-plugin:
Code
Index: src/plugins/contrib/profiler/cbprofiler.cpp
===================================================================
--- src/plugins/contrib/profiler/cbprofiler.cpp (revision 1828)
+++ src/plugins/contrib/profiler/cbprofiler.cpp (working copy)
@@ -85,11 +85,12 @@
  if (project->GetBuildTargetsCount() > 1)
  {
  // more than one executable target? ask...
- wxString choices[project->GetBuildTargetsCount()];
+ wxString* choices = new wxString[project->GetBuildTargetsCount()];
  for (int i=0; i<project->GetBuildTargetsCount(); i++)
     choices[i] = project->GetBuildTarget(i)->GetTitle();
  wxSingleChoiceDialog dialog(Manager::Get()->GetAppWindow(),_("Select the target you want to profile"),
                                  _("Select Target"),project->GetBuildTargetsCount(),choices);
+        delete[] choices;
  dialog.SetSelection(0);
  if (dialog.ShowModal() != wxID_OK)
     return -1;
It seems as if there were arrays with a variable length used. But this is a feature of C99 and *not* C++98. New gcc versions seem to support this for C++, too, but it is not correct.

Another thing is: I used the linux build system. Switching to icc is quite easy, just add CXX=icc CC=icc when invoking the configure-script. But icc doens't understand the same commands for building precomipled headers as the gcc. This means that precomipled headers must be disabled or the flags must be changed to make word with icc, too (anyway, I wasn't able to do this). But adding --enable-pch=no to the configure-call doens't work - configure fails with an error message:
Quote
configure: Configuring Code::Blocks...
configure: error: conditional "PRECOMPILE_HEADERS" was never defined.
Usually this means the macro was only invoked conditionally.
Thus i had to remove the parts for precompiled headers manually from 'src/sdk/Makefile.am' and 'src/plugins/contrib/wxsmith/Makefile.am'.

But then it works, icc just shows a few warnings about parameters it doesn't understand, like '--fast-math'.
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
Real Programmers don't write in BASIC. Actually, no programmers write in BASIC, after the age of 12.