Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: 280Z28 on January 22, 2006, 04:13:56 am

Title: Compiling Code::Blocks with the MS compiler
Post by: 280Z28 on January 22, 2006, 04:13:56 am
The SVN version doesn't compile with it.

Is anyone even interested in support for this?
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: takeshimiya 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.
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: 280Z28 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:
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: rickg22 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?

Title: Re: Compiling Code::Blocks with the MS compiler
Post by: 280Z28 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. :)
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: takeshimiya 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.  :)
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: 280Z28 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. :)
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: Ceniza 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.
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: 280Z28 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.
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: Ceniza 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.
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: 280Z28 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
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: 280Z28 on January 22, 2006, 09:57:30 am
I got all the plugins from the main project working in it :)
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: killerbot 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.
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: takeshimiya 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
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: Der Meister 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'.
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: Michael on January 22, 2006, 03:29:51 pm
The compiler with VS 2005 is one of the most compliant compilers available.

VS 2005 is a relatively good ISO-C++ compliant compiler (for sure better than Visual Studio C++ 6), but may be you would like to give a look at here (http://forums.codeblocks.org/index.php?topic=1670.0).

Michael
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: Michael on January 22, 2006, 03:38:44 pm
[EDIT] It would indeeed by nice to have CB and plug-ins compilable with different compilers, but stick to the standards...

Yes, IMHO it would be really nice :D. Anyway, this will provide additional work, because all the C::B and plugins modifcations, updates and so on need to be checked with all the supported compilers.

Michael
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: 280Z28 on January 22, 2006, 04:29:37 pm
I wanted to use Visual Studio to track down the code completion bug I was facing, and I'd just like to say that within 2 minutes of running CB within the VS debugger for the first time, I found the problem.  :shock: :lol:

Rick, you aren't using a Pentium 4, are you? :o
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: Ceniza on January 22, 2006, 04:38:25 pm
Quote from: 280Z28
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

Obvious reason to deprecate? Defining another macro to make this specific compiler behave and stop throwing things it'sn't supposed to?

The reason to deprecate something in a compiler is because the standard says so. C99 and C++98 haven't deprecated that, it's plain wrong for a compiler to start adding deprecations here and there because they want to.

If they just showed a warning suggesting the use of another STANDARD function or read why you should use those functions carefully, that'd be fine, but no, they don't. An example of this is using gets with gcc under Linux. gets hasn't been deprecated, but should be used with care or replaced with a call to fgets or anything else, but just because it's "insecure" doesn't give "obvious reasons" to the compiler to call it deprecated.

And then what? Will MS just remove those functions in the next release because were deprecated in the current version?

But anyway, if you can find something useful in the whole process of modifying the sources to make them compile with that compiler and not just having that compiler telling lies, that'd be good.
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: 280Z28 on January 22, 2006, 04:45:17 pm
I disagree with you, but I guess that's ok because you'll never be using the VC compiler in the first place and I have a property sheet to add that to macro to projects I'm converting. ;)
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: 280Z28 on January 22, 2006, 04:50:52 pm
I'd like to just check in the fix rather than going through all I did to fix it. Is that possible?
Title: Re: Compiling Code::Blocks with the MS compiler
Post by: Ceniza on January 22, 2006, 04:51:37 pm
Rick hasn't a P4, but you'ren't saying what problem you found.

Would you mind to explain how P4 and CodeCompletion relate there? :)