harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [general] Add a new target for Harmony-Select in the build script
Date Mon, 12 Apr 2010 07:31:19 GMT

In message <t2x5c8e69f1004090121t70353ef6xe8c8851c9a3f2559@mail.gmail.com>,
"Jimmy,Jing Lv" writes:
> Hello Everyone,
>     I'd like to raise the topic of "Harmony-Select"
> again. Harmony-select, as we discussed, is aimed to create a
> customized build without graphic components. The select build will
> then be smaller in the footprint. It is specially useful for the
> customer applications which does not require awt/swing (as many j2ee
> apps, java DBs, and applications like eclipse, Hadoop etc)
>     Thanks to Harmony modularization, it is quite easy to create this
> select build. And currently there is no special requirement on the
> source, we can make a select build without forking a new branch. My
> plan is:
> 1. add a new target in the \classlib\build.xml, say, build-select,
> including build-select-java, build-select-native and build-select-test

In general I'd be against adding new targets.  The name of an invoked
target is not propagated by ant.  Think about the consequences of what
you are suggesting, we'd need to add:

 a) a similar number of new targets to federated/build.xml
 b) bundle-select-hdk and a number of related targets to federated/build.xml
 c) bundle-select-src and a number of related targets to federated/build.xml
 d) possibly a number of targets to federated/classlib/make/build-*.xml

I'd much rather add a -Dhy.select=true option as this can be:

 a) propagated down from federated build to classlib (and potentially other
    components if we want/need to - do we want all the jdktools in select?)

 b) saved/restored from a properties file

> 2. build-select targets will operate like normal ones, just exclude
> graphic components:
>  ACCESSIBILITY      APPLET              AWT
>  IMAGEIO            ORB                 PRINT
>  RMI                SOUND               SWING      X_MGT

Why couldn't -Dhy.select=true just modify the default value for

> 3. Then deploy the necessary materials including jars, property files
> and binary under deploy-select/. A small problem here is that we
> have define the output directory (deploy/jdk/jre/lib/boot) in every
> module. I don't have a perfect solution now to modify that, but only
> to copy them from deploy/ to deploy-select/

I'm not sure why we need to do copying?  Why would deploy/ contain more
than deploy-select?  (Aside: I am somewhat slowly trying to remove
unnecessary copying from the ant files.  I did quite a bit of work on
the build-native steps in classlib and this resulted in significant
improvements to build times.)

>      I'd like to start in harmony6 level, and change directly with
> the build scripts. It seems it does no harm to any other normal
> build. After that, we can simply invoke:
> \> ant build-select
>      to get a select build under deploy-select/

We normally do new work in trunk and merge to java6 and not the other
way around?  Do you have a reason to do the work in java6 rather than

>      Any comments/suggestions? I'll commit a patch to the build
> scripts if there is objection.

"commit" if _no_ objections I assume? ;-)


View raw message