You'd have to check them out as modules, and then the sources would be
used on your machine instead of the static copies.
But we'd probably not accept bug reports from such builders without
you having checked the static versions first (just as we always refer
people to official install/boot CDs to rule out any local building
issues).
On 2009-11-02, at 12:09 PM, King InuYasha wrote:
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(a)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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev