harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: Supporting working on a single module?
Date Tue, 09 May 2006 14:32:45 GMT

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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message