2 Dec
2009
2 Dec
'09
10 p.m.
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(a)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
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev