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

[KJK::Hyperion <no...@li...>]

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:
  - 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
  - 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>
  - empty, dead directories. I know this is because of limitations of CVS, 
but sure it's annoying
  - 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?

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
  - no support for the CodeView symbol format, only the "ancient" textual 
symbol lists
  - no BUILD utility. This means they have to maintain separatedly a 
makefile for ReactOS and DIRS/FILES files for the Microsoft DDK. 
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?
  - 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?