Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <44929675.3020409@pobox.com>
Date: Fri, 16 Jun 2006 07:31:01 -0400
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Simplifying the ant files?
References: <200606161123.k5GBNmNb017204@d06av02.portsmouth.uk.ibm.com>
In-Reply-To: <200606161123.k5GBNmNb017204@d06av02.portsmouth.uk.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Mark Hindess wrote:
> On 16 June 2006 at 6:37, Geir Magnusson Jr <geir@pobox.com> wrote:
>> Mark Hindess wrote:
>>> 3) Currently the 'build' target automatically does a 'clean'.  I think
>>> this dependency should be removed and a new target - 'dist' perhaps? -
>>> should be created for doing non-incremental builds.
>>>
>>> [Geir has already fixed the first part of this since I started writing
>>> this.]
>> I don't like "dist" - to me that's been traditionally reserved for
>> making a distribution (funny that...).
> 
> dist was just the first thing I thought of but you are correct it isn't
> quite right.
> 
>> Maybe "rebuild"?
> 
> That would do.
> 
>>> 4) Also at the module level, I think we should compress the two layers
>>> of make/build.xml and make/common/build.xml.  For one thing it is very
>>> confusing, that:
>>>
>>>   a) modules/auth/make/common/build.xml builds the platform-specific
>>>      java code, and
>>>
>>>   b) modules/luni/make/platform seems to be related to what we've been
>>>      calling native code not about platform-specific java code.
>>>
>>> It would be crazy to separate building of platform-specific and
>>> platform-independent java code because we'll only have problems
>>> handling dependencies and it would mean a lot of duplication.
>>>
>>> Even if we renamed 'platform' to native, I still don't think the
>>> separate build.xml is needed since all it would ever do - in the near
>>> future when we start moving the native code - is call straight out to
>>> a makefile (or configure or whatever) so I don't think this extra
>>> layer would add much.
>> I lazily decided not to parse this, but I've been w/ you so far so I'm
>> sure it's fine.
> 
> Don't blame you. ;-)
> 
>> But please...  Please...  Please....
>>
>>   s/hy/harmony/
> 
> I'll let you and Tim argue that one. /me lights touch paper and runs ;-)

The Readability Battle of 2006 has begun!

> 
>>> 8) Running "ant -f make/build.xml" from a module sub-directory doesn't
>>> actually clean the main compiled classes. 
>> As it shouldn't IMO..
> 
> Sorry I wasn't clear on this. I was thinking:
> 
>   <delete failonerror="false">
>     <fileset dir="${hy.build}"
>              includesfile="${hy.nio}/make/patternset.txt" />
>   </delete>
> 
> which is to say, delete the things that this module created.

Right - I just meant that "clean" shouldn't be default action.

> 
>>> (I think this is pretty
>>> important to getting consistent expected behaviour so I'm looking at
>>> this right now and will fix it shortly unless anyone shouts.)
> 
> And now I have a patch ready to go in.
> 
>>> Well, these are some of the things that are bothering me.  I suspect
>>> others have other issues?
>> Yes.  It bugs me to no end that "build" isn't where we keep build
>> stuff.  It may simply be because I've hung around Jakarta and related
>> too long, but the convention I'm used to is "build" is where build
>> stuff goes (don't use "make") and "target" is the created directory
>> where the build churn happens.
> 
> When I was looking at the commons projects I'm sure there was a mixture
> of both build and target for built artifacts.  I'm easy.  (Tim:
> specifically about this not in general. ;-p )
> 
>> This really is an aesthetic rather than technical argument, and so
>> I've kept my mouth shut until now, but I've decided to come out on
>> this one here... :)
> 
> I've never been very good at "keeping my mouth shut", I really don't no
> how people manage it. ;-)

It's a useful skill.  I've had to work on it a long time, and still
working on it...

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