"It's like NT does" isn't an advantage... cloning *build methods* of the Core OS Division at Microsoft doesn't do anything positive (nor negative) to the quality and reliability of the code. You have to look at *what* the method involves and analyze that way.
Your other argument applies: building RTL multiple times reduces the need for the small support library ReactOS uses and gives one consistent place for RTL code.
Disadvantages: - Building RTL up to 4 times, increasing build time substantially (rtl is a pretty big library). - Quadruple-conditional compilation...meaning people will have to test their rtl changes by BUILDING FOUR TIMES with different conditionals. Will people really remember to do this? Will people really write code knowing exactly what do ifdef and where, and how? - To do this right, you'll need a host-rtl too. Have fun writing one. - Right now the commit did only half the work -- now compile time is doubled, but libsupp is still there, making the situation even worse. The commiter made the assumption "other people" will pick up the slack, which probably won't happen, and this will rot forever.
Best regards, Alex Ionescu
On Wed, Oct 15, 2008 at 2:41 PM, Aleksey Bragin aleksey@reactos.org wrote:
I knew about this post-factum, so let's gather opinions.
Advantage: It's like NT does, less hacks, possible removal of libsupp stuff in ntoskrnl, freeldr, ntdll, etc (which I actually thought would be done in the same commit).
Disadvantage: To be proper, you need a bootloader RTL too, otherwise RTL will still contain "necessitating hacks" aka libsupp stuff. This is gonna make at least 3x time RTL compilation. (thankfully / sadly we don't test it directly).
WBR, Aleksey.
On Oct 15, 2008, at 10:02 PM, Alex Ionescu wrote:
Well, you just removed the one thing ReactOS did different from NT and that I thought was really revolutionary and innovative, because it saves on compile time. It's funny, because I've been trying to sell this as a better approach to building RTL (It's built at least 4 times in the real NT tree, I think -- loader, user-mode tools/testing, kernel, user-mode).
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On Oct 16, 2008, at 12:24 AM, Alex Ionescu wrote:
- Right now the commit did only half the work -- now compile time is
doubled, but libsupp is still there, making the situation even worse. The commiter made the assumption "other people" will pick up the slack, which probably won't happen, and this will rot forever.
That's why I want to reach a decision about this as soon as possible.
Also, about grouping out the environment independent code out of the RTL in to some imaginary RTL_INDEP library, and having smaller RTL_UMODE, RTL_KMODE, RTL_BOOTLOADER, RTL_HOSTTOOL libraries, I find this wrong, because it adds complexity over the method we had (using a support library), but gives no real benefits.
WBR, Aleksey Bragin.
If there is no decision made today, I will get it back to the previous implementation (fixing those bugs uncovered during this transition).
I don't want it to be another 5-years story (like the one uncovered by Stefan in cmlib, which also needs a libsupp, and right now does no interlocking at all).
WBR, Aleksey Bragin.
On Oct 16, 2008, at 12:25 PM, Aleksey Bragin wrote:
On Oct 16, 2008, at 12:24 AM, Alex Ionescu wrote:
- Right now the commit did only half the work -- now compile time is
doubled, but libsupp is still there, making the situation even worse. The commiter made the assumption "other people" will pick up the slack, which probably won't happen, and this will rot forever.
That's why I want to reach a decision about this as soon as possible.
Also, about grouping out the environment independent code out of the RTL in to some imaginary RTL_INDEP library, and having smaller RTL_UMODE, RTL_KMODE, RTL_BOOTLOADER, RTL_HOSTTOOL libraries, I find this wrong, because it adds complexity over the method we had (using a support library), but gives no real benefits.
WBR, Aleksey Bragin.