Timo Kreuzer wrote:
Curently the SDK is integral part of the whole source tree. One minor change can cause massive rebuilds even if not needed. The import libraries are even part of the modules that export the functions which is stupid, because the interfaces are expected to be stable.
Reorganizing the source dependencies etc to ease partial OS rebuilds and facilitate app development without dependency of OS source is of course a good/necessary step.
It may be a superfluous remark, but in all of this, I hope You don't loose sight of that the goal is to loose any up-layer calls in the architecture itself, so a subsystem change don't cause a core incompatibility. F.ex Win32 is by design a subsystem layer, and should have a stable interface to the native core of the OS, and the core should *not* call subsystem functions. Due to this we will (probably) need a 'glue' dll besides ntdll, where we put primitives for the core to use wherever it was calling subsystems. I don't really think we *have* to draw the core lines where MS did. Our ntoskrnl seems a prime candidate as it stands. Perhaps a superfluous remark?
I would suggest a configurable [SDK] path. So that multiple reactos checkouts could use one SDK checkout. Each of the main checkouts contains a config file with the sdk path.
Should it not be the other way around also ? That the SDK would have a configurable path to the OS subversion you're working with if you're f.ex trying to regress an app malfunction, so your binaries end up in the right place.
Sources\ \reactos-trunk... \reactos-amd64... \reactos-arwinss... \reactos-sdk\ \include\ \lib\ <- static libs (crt, nt, ...) here \import\ <- spec files here \rosapps\ \rostests\
IMHO the current source tree structure is not too bad as it is. I don't think any *major* reshuffling under 'trunk' is required.
Making an 'sdk' directory as a sibling of 'trunk', 'tags', et. al. Separating all 'public' headers and libs (including 3rdparty) and putting them under 'sdk' (I think this is the most daunting task), so that 'reactos\include' and 'reactos\lib' will contain only 'os internal' headers and libs.
It occurs to me that the public headers would be more or less a drop-in replacement for the ones in the MS SDK, with anonymous stub declarations for internal data structs and so on. It might be an interesting test to try an app build with their headers instead of our own, but maybe someone tried that already ?
Under 'trunk' I think only some minor shuffling could be good. Moving prog source like f.ex 'mode' and 'sort' which are fundamental parts of a full ReactOS to 'base\applications' instead of 'rosapps'. Likewise moving user callable progs like 'format' from 'base\system' to 'base\applications' so 'base\system' will contain progs that are only called by the system, not by the user. Yes ? No ?
It would probably be a good idea to sync our headers / libs with mingw-w64 as much as possible
Probably.. but I hope You don't mean to use them verbatim. I think MinGW's headers are rather hideous with their dense format and total lack of comments, so I'm no huge fan of them. I don't know about You, but to me the headers are usually the main documentation!
Other seperations like core / win32 / wine etc can be done in a similar way.
Frankly, I think the current code structure could stand in this regard. One may already checkout only f.ex 'ntoskrnl' to work on the core and 'subsystems' already has it's separate directory etc.
I would also suggest that "clean" command gets fixed. Currently it always deletes all stuff from the specified source folder. Even if I am executing it from a different checkout folder. That sucks. It should only clean everything in the current folder.
Good point. Sounds reasonable to me too. Then 'clean all' can do what 'clean' does today ?
Just some food for further thought. Rock on // Love