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 <ionucu@videotron.ca> 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 <timo.kreuzer@web.de> 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
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>

_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev