3 Nov
2009
3 Nov
'09
11:32 a.m.
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