Sorry I havnt replied sooner Thorbjørn - I have been off list the last
few days
or so, and am still wading through all the mail. I think Marks response
summed up
what I was thinking pretty well but Ill go through and check...
Mark Hindess wrote:
On 5 July 2006 at 13:39, =?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?= <[EMAIL
PROTECTED]> wrote:
Oliver Deakin skrev den 27-06-2006 12:25:
Do you mean the header files in deploy/include? If so, the reason
they are copied there is so that they are in a shared location for
all modules. (In fact it's the same reason that libs are built into
deploy/lib and makefile includes are copied into deploy/build/make).
So it is basically a platform agnostic symbolic link?
No. It is intended that modules can build against the resulting deploy
tree without having to know about the structure/location of the other
modules.
Exactly - the deploy directory will contain all build dependencies for
modules
in Harmony classlib. There is no direct internal dependency at build
time from
one module to another (ie for header file location etc.), only a dependency
on the contents of the deploy directory. A module can then just add the
deploy/include and deploy/jdk/include directories to its include path, and
expect all its dependencies to be satisfied.
Personally I do not like doing it so, would it be possible to do it
with -I's instead so we do not have redundant copies lying around?
You could use -I flags but then each module would need to know the
location of the header files of the other modules. It would also
mean we'd need to separate the header that describe internal APIs and
external APIs within modules making the include paths within modules
more complicated. Now it is quite clear what represents the external
API - only the headers in deploy.
Yup - the headers in deploy create a native interface layer between the
modules.
As a consequence, they could also *only* checkout the module they
are interested in, rather than the whole of classlib/trunk, and
still be able to rebuild their altered code.
I have heard this discussion, but I am not convinced that having lots
of different building enviroments is a good idea.
But the key here is that since even when you check out everything you
are still building against deploy so in fact the build environment
from the perspective of a single module is actually identical _not_
different. (Thaft is, no matter how a module is built it's always
building against what is in deploy and never peek directly in to other
modules.) I think this is important to ensure that modules are always a
well-defined unit that can be replaced.
Agreed - the idea was to make the modules depend only on the
shape/content of
the deploy directory, and not the other modules. So if a module changes
shape,
disappears or gets added, as long as it puts the right stuff into deploy
then all the
other modules are happy.
Regards,
Oliver
I can however also appreciate tolerable build times :)
Agreed, but I don't think that is the main motivation.
Regards,
Mark.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
