Re: [ros-kernel] Some thoughts on the source tree and build system

[Eric K. <ek...@rz...>]

"KJK::Hyperion" <no...@li...> wrote:

Hello, KJK::Hyperion!


> Hi all. I think it's time to review and/or fix our rather messy repository
> before it's too late and while the project is relatively inactive. Let's
> recap the known faults and kludges:

It is never too late. It is only getting more and more work to fix the
issues. ;-)

>   - a TON of duplicated code. We all know the hideous amount of identical
C
> runtime functions that MSVCRT, CRTDLL and NTDLL happily implement each by
> its own. MSVCRT and CRTDLL also have duplicated streams (stdio.h)
> libraries. NTDLL and NTOSKRNL contain two distinct duplicates of the RTL.
> In most of these cases even the compiled binary objects could be shared

IMO it is mostly a question of required disk space versus readability. I
don't like to move to another 'common' directory to have a look at a
function which is shared by multiple binaries.

Another point is the MSVCRT vs. CRTDLL and NTDLL vs. NTOSKRNL thingy. These
two pairs of binaries seem to share a lot of code but when you have a close
look at them, you will see that they are not the same! For example, MSVCRT
and CRTDLL seem to export the same functions. But they are *not* the same.
MSVCRT should be thread-safe and CRTDLL must not be thread-safe. The
situation is similar for NTDLL and NTOSKRNL. Have a very close look at the
Rtl-functions

>   - the build system isn't the best at handling dependencies.
Specifically:
>      - it doesn't always fully exploit the topological sorting implemented
> by make, but it requires in several cases to specify explicitely the build
> order of targets. An example is our master makefile
>      - inter-target dependencies have to be handled manually. This could
be
> solved with the monolithic makefile approach described in the paper
> "Recursive Make Considered Harmful", available at
> <http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html>

Agreed!

>   - empty, dead directories. I know this is because of limitations of CVS,

> but sure it's annoying

Agreed!

>   - no separation of Win32 and native applications, libraries and
services.
> And they cannot be moved because of, again, CVS limitations (AFAIK). What
> was the name of that other, better version system again?

Agreed! I guess you mean 'arch'. Since you are complaining about CVS, would
you volunteer as an arch-tester and try to find out whether it suits our
needs?

> That's not the whole story. I subscribed to the OSR ntdev mailing list,
and
> read the discussions of many real-world NT driver developers for months.
We
> don't want to alienate our possible future commercial partners, right?
> Here's what our tools and environment lack compared to those they're used
to:
>   - no clear separation of "debug" and "release" builds

Agreed!

>   - no support for the CodeView symbol format, only the "ancient" textual
> symbol lists

That's not a real issue because gcc can generate much better debugging
information. It's nm that extracts the 'ancient' .sym files.

>   - no BUILD utility. This means they have to maintain separatedly a
> makefile for ReactOS and DIRS/FILES files for the Microsoft DDK.

Is there any technical reason to switch to BUILD? IMO, using make is
sufficient because developers will not use the (not yet existing) ReactOS
DDK and the Microsoft DDK at the same time. The MS DDK is incomplete and no
longer freely available. The only advantage of the MS DDK is the
documentation. IMO, there is no reason to switch from the ReactOS DDK to the
MS DDK but a lot of reasons to switch to the ReactOS DDK. And MS will surely
no longer permit the use of the their DDK for 'evil GPL' drivers. ;-)

> Micromanagement is evil
>   - we mix source files with generated binaries. This is messy, and
> inflexible: how do you handle multiple different builds of some target?
for
> example "debug version for the i386 architecture, with Microsoft Windows
> compatibility options, statically linked", "release version for the SPARC
> architecture, with support for large files", and so on?

Agreed! Don't forget the Uniprocessor vs. Multiprocessor issue!

>   - while some could find cool having an integrated local kernel debugger
> (PICE), many more others would hate not being able to use WinDbg for
remote
> debugging
>
> I think I'm done now :-) Hope I didn't sound rude or something
> Comments?

No, you don't sound rude! At least as long as you volunteer for at least one
of the tasks. Otherwise I'll have to call you greedy. ;-)


Btw, could you consider using your real name on the ReactOS lists? I feel
like I'm talking to the pole of a streetlight. ;-)


Regards,
Eric Kohl