Mark Hindess wrote:
As the Harmony Classlib grows, I think that being able to work on a
single module (or some subset of the modules) will become the typical
way of working for many (perhaps even most) contributors.
Sure, that makes sense.
So I think
we need a plan to support this. I also think that forcing ourselves
to support this mode of working sooner rather than later will help us
keep from accidentally breaking the modularity in the current
build/development process.
Can you not work on a single module now?
Oliver is currently looking at restructuring the native source to the
appropriate modules/*/src/main/native directory.
Can he talk about it out here, or is this for your internal use?
One question that
comes out of this investigation is: where should the include files
"live"? I think they belong with the module that provides the
implementation defined by the declarations in the header. That is,
zipsup.h is "owned" by archive, hythread.h is "owned" by thread
(luni), etc.
Sure - that makes sense.
However, if the build was to refer to the header files within the
modules then this breaks the modularity. So, for example, someone
working on a single module would have to checkout all the dependent
modules rather than just the one they wish to work on.
So, perhaps, at build time we should copy the header files out of the
owning module into a common include directory. All modules would then
refer to the header file in the common include directory. This means
we can then create a snapshot tar/zip of the common include directory
which someone wishing to work on a single module could download to
build against. This is not dissimilar to the current way in which
you could build the java sources against a deploy/jre snapshot.
Why wouldn't someone wishing to work on a single module just checkout
all the code? I'm really wary about having non-SVN-sourced artifacts
meant to be used in building/development. Smells a bit like the first
step towards the classic Windows "dll-hell".
For windows, the snapshot would also include the .lib files that are
required to build for the run-time .dll files.
What is this new snapshot? Well, Tim suggested
(Where?)
that it was a little
like the jdk but for Harmony development. So perhaps it should be
called an hdk, Harmony Development Kit?
I'm missing the point... why wouldn't a developer checkout head, build
that, and then get to work on whatever part of whatever module they wanted?
Logically, in the same way that a jdk contains a jre, the hdk should
contain the jdk (which will contain the jre). Thus, we'd have a
hierarchy like:
deploy/hdk
deploy/hdk/jdk
deploy/hdk/jdk/jre
When we come to create snapshots/releases, it's easy to see how we'd
create archives for the hdk, jdk, and jre.
Unfortunately, though I think this solution is quite elegant, there
are quite a few references to the "deploy/jre" path that would need to
be fixed. However, I think this is something we should discuss and, if
we decide it is the right thing to do, then we should take the hit and
move things around now.
What do you think?
I don't understand the basic problem you're trying to solve... Maybe
because this is the first I've heard of any problems related to this, or
I wasn't paying attention.
Is it that since modules reference other modules, working in one module
means you need the dependent modules around?
A long time ago we talked about something like this, a pre-build step
that produces a "hdk"-like set of artifacts that a developer could then
use if they were focused down inside a module.
Is this the same thing returning for discussion?
Couldn't we just use a standard snapshot? Take the latest nightly, drop
into some magical place in the tree, and then go into your module and
work from there?
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
