3 Nov
2009
3 Nov
'09
1:53 p.m.
Love Nystrom wrote:
The binaries are always placed in the appropriate folders beneath your
toplevel checkout folder. If you use multiple checkouts of the same
source (branches), you wouldn't want to reconfigure your SDK each time
you want to compile the other branch. It also doesn't make sense, as the
SDK stays the same, no matter what you use it for. Or are you talking
about the target OS version defines? These are managed in the source
checkout, too.
To claryfy, the above was thought as local folders on your harddisk, not
the repository.
Regarding the repository, IMO the current structure is complete crap. It
mixes core and subsystem, win32 and NT, audio and network, 3rd party and
reactos all under the same folder because the modules happen to have the
same extension. Bigger commits usually spread through multiple top level
folders, though they only affect one functionality.
Maybe. We could try to make sure our headers are minimum as complete and
correct as mingw headers and with more documentation, then maybe
mingw-w64 people would be interested in using them.
For DDK headers we could use an autocreate way like MS does. Create a
set of *complete* headers and autocreate wdm, ntddk, ntifs, etc from them.
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
The source / sdk separation is a different task, but a neccessary step
in that direction.
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?
We do this already. The nt-core includes ntdll in usermode. And of cause
ntdll doesn't call win32 functions. And ntoskrnl doesn't call win32k
functions. (Except callbacks)
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.
Moving the stuff is the smaller part. Getting the stuff right beforehand
(complete and compatible) is the bigger task. Getting everyone fix their
checkouts is probably the biggest part ;-P
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
Thats the point, yes.
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 ?
Most of our apps should build fine with ms headers. I never did it
myself, but afaik other people are doing that regularly.
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'.
LOL, mode and sort are fundamental? I think you didn't quite get the
idea of MinWin / MinRos. This is everything but not fundamental. I think
I never even executed one of them on reactos. Or windows. We could as
well delete them and noone would care.
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!
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.
And it's all wrong.
user32 and gdi32 are parts of the win32 core subsystem. they are in
dlls/win32 mixed with all the wine stuff.
ntdll is part of the nt-core and it's also in dlls, just next to
keyboard layouts and control panel applets.
freeldr is part of the ntcore and in the boot folder
kdcom is part of the ntcore and in drivers/base.
etc etc
Show me how to checkout ntoskrnl only and build that. You need the whole
tree to build anything.
Good point. Sounds reasonable to me too.
Then 'clean all' can do what 'clean' does today ?
"clean" currently cleans the folder you specified when you installed
rosbe. The current folder stays untouched.
Regards,
Timo