So would the sources of the binary modules still be available in the tree? Because I personally like to compile everything to be set dynamically instead of using static libraries.
On Mon, Nov 2, 2009 at 10:43 AM, Alex Ionescu <[email protected]> wrote: > There are all things that KJK and myself have been striving to work > on. They require changes to rbuild's underpinnings, which have yet to > happen. There is a Wiki tracking some of this. > > The end plan is for us to ship an RDK which would ship with > > 1) Public SDK (libs and headers) > 2) RosBE > 3) Rbuild itself > > And those binary modules would be used unless the source module was > imported into the tree (say you wanted to have your own rbuild or make > changes to it). > > This would add major stability and testing consistency so everyone > builds with the same headers, libraries, build scripts and > rbuild/compiler version. > > The extended plan is to add things like mesa and other 3rd party > libraries as binary-only packages in the RDK as well -- again allowing > for the option of these to be compiled by hand if the user wants to, > but normally the static versions would be linked, saving compilation > time and disk space. > > Best regards, > Alex Ionescu > > > > On Mon, Nov 2, 2009 at 11:14 AM, Timo Kreuzer <[email protected]> wrote: > > > > One thing related to this is the sepeartion of the SDK part. > > > > 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. > > > > Separating the SDK completely from the sources is not possible atm, but > > I suggest separating it from the main folder. > > It could be done similar to how rosapps and rostets are managed. As a > > sepeate checkout. But instead of putting it into the hardcoded modules > > subfolder, I would suggest a configurable path. So that multiple reactos > > checkouts could use one SDK checkout. Each of the main checkouts > > contains a config file with the sdk path. A default path could be set by > > RosBE or in the config-template. I would suggest to do that with rosapps > > and rostests, too. So you only need one checkout of rostests for > > multiple base checkouts. You can probably do that with hardlinks but not > > everyone can/wants to do that. > > The libraries would only be rebuild if you update the SDK. > > > > Sources\ > > \reactos-trunk\... > > \reactos-amd64\... > > \reactos-arwinss\... > > \reactos-sdk\ > > \include\ > > \lib\ <- static libs (crt, nt, ...) here > > \import\ <- spec files here > > \rosapps\ > > \rostests\ > > > > It would probably be a good idea to sync our headers / libs with > > mingw-w64 as much as possible, so maybe some day we could actually > > outsource the whole SDK. > > > > Other seperations like core / win32 / wine etc can be done in a similar > way. > > It would require to have multiple checkouts to compile, but I think > > that's a reasonable efford. > > Or all parts could be put into trunk/source/... then you can checkout > > the whole folder if you don't want to hassle with multiple checkouts or > > trunk/source/sdk/ and trunk/source/reactos seperately if you like. > > > > 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. That way modules / the sdk > > would not automatically be cleaned. Because that's in most cases not > > what you want. A "clean all" could be used to clean all dependencies as > > well. > > > > Regards, > > Timo > > > > > > > > _______________________________________________ > > Ros-dev mailing list > > [email protected] > > http://www.reactos.org/mailman/listinfo/ros-dev > > > > _______________________________________________ > Ros-dev mailing list > [email protected] > http://www.reactos.org/mailman/listinfo/ros-dev >
_______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
