harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Gorr" <vvg...@gmail.com>
Subject Re: Supporting working on a single module?
Date Wed, 10 May 2006 07:59:02 GMT
Whether do I correctly understand it's supposed to modify the existent build
system? I mean the following.

Each of modules (or components) has the native (shared & platform specific)
and Java parts.

As a rule these components will be built with similar way. If there is any
specific (compile options, for example)

the property file will be created for this component and used for the build
purpose. The rest of classes and libraries

needed to compile will be taken over the snapshot. All component
deliverables will substitute the original ones from

the snapshot. In this case the developer needs to download only the
component sources for development process.



Is my understanding correct?



Thanks,

Vladimir.


On 5/10/06, Mark Hindess <mark.hindess@googlemail.com> wrote:
>
>
> On 9 May 2006 at 22:33, "Nathan Beyer" <nbeyer@kc.rr.com> wrote:
> >
> > Perhaps this is a bit of an aside, but one of the biggest difficulties I
> > have when trying to develop against a single module is the availability
> of
> > the test support classes. Currently, I run the ant build and run the
> > 'compile-support' to build the test support classes. Then in Eclipse, I
> > create a linked folder to the 'build/tests' in the module I'm working on
> and
> > then add that folder to the classpath of the project.
> >
> > As such, I would like to propose adding a packaging of the support
> classes
> > to a JAR in the build scripts and include this as part of the discussed
> > snapshots.
>
> Nathan,
>
> I agree.  This is precisely the kind of thing that the 'hdk' snapshot
> would need to contain to fully support modular development.
>
> -Mark.
>
> > > -----Original Message-----
> > > From: Mark Hindess [mailto:mark.hindess@googlemail.com]
> > > Sent: Tuesday, May 09, 2006 9:07 AM
> > > To: Apache Harmony Dev List
> > > Subject: Supporting working on a single module?
> > >
> > >
> > > 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.  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.
> > >
> > > Oliver is currently looking at restructuring the native source to the
> > > appropriate modules/*/src/main/native directory.  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.
> > >
> > > 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.
> > >
> > > 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 that it was a little
> > > like the jdk but for Harmony development.  So perhaps it should be
> > > called an hdk, Harmony Development Kit?
> > >
> > > 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?
> > >
> > > Regards,
> > >  Mark.
>
>
>
> ---------------------------------------------------------------------
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message