FYI: I did know about the C::B backend. I knew for a LONG time about it. I started downloading and building ReactOS and trying it out around the 0.2.9 release, and I already knew that the C::B backend was not fully functional.
The main flaw with the MSVC import system is that it doesn't translate the compiler options over, all it does is stick them under custom options and wipe the option set clean. If the projects are really simple, it sets some options (like if the project is for a DLL, it sets the options suitable for a DLL, but lots of cleanup has to be done).
I actually wanted to try to understand rbuild to see whether I could improve C::B support or convert it to cmake so that Cmake could be used to generate C::B project files. The thing is, I don't know anything about rbuild. I have asked in IRC before, but I usually don't get any useful answers from there, and the wiki isn't very helpful either.
If you want to rag on C::B's import system, then improve it! After all, doesn't every OSS dev that doesn't or can't do something say "Patches Welcome!" As much as I hate that phrase, it's appropriate to fling it at someone who gripes about an open source program and doesn't want to do anything about it.
You know what... Forget it, rbuild is probably going to wind up only being a wrapper around the MSVC buildsystem anyway, since it seems it can be justified that all other systems can be ripped out because "importing MSVC projects is possible." Nevermind that importing MSVC projects has never been reliable in any alternative IDE.
On Wed, Dec 2, 2009 at 3:12 PM, Colin Finck
<mail@colinfinck.de> wrote:
Sir Gallantmon wrote:
> The import support for MSVC projects is not perfect, so it shouldn't
> be relied on.
Well, then it should be the Code::Blocks people who better improve their
import system.
It would benefit them more than us, because they would improve the
compatibility with lots of MSVC projects out there.
If we would have enough manpower to maintain the Code::Blocks backend and
see the advantages in using it, we would most-likely keep it. But as there
is already a consent among the devs that this backend is a candidate for
deletion, it should be obvious that we don't have the manpower.
The Code::Blocks people should rather have it, because they can exclusively
focus on creating an IDE while we currently need to care about Build
systems, code all the way up from kernel-mode to user-mode, the Website
components, etc with just a small team.
Just my 2 cents for justifying in detail why we're removing the backend.
Best regards,
Colin