ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: [PATCH] refactoring of javac task into factory
Date Sat, 16 Dec 2000 02:43:11 GMT
At 09:28  15/12/00 -0500, Jay Glanville wrote:
>> I am not sure I like it ... as a
>> matter of fact I don't like it. 
>> It will now encourage users to create
>> incompatable build files by hardwiring compilers into the the 
>> build file ;(
>
>I'm not sure I understand your concern.  It was my impression that we wanted
>to get away from "magic properties" (the build.compiler is an example of
>one).  It's relatively easy to go through the ant-dev archives looking for
>"magic properties" to find people saying they want to reduce their usage.
>The only way that I thought that we could get rid of them is to replace them
>with explicit attributes of a task.

yep - thats one way ;)

>On the subject of the "creation of incompatable build files by hardwiring
>compilers into the build file", let me show you how this new attribute
>PREVENTS that!  Lets look at the following build.xml snippet:
>   <property file="designer.overrides.properties" />
>   <property name="prop.compiler" value="modern" />
>   <javac compiler="${prop.compiler}" .../>

It relies on people being intelligent about it. I prefer to think of people
as stupid/lazy and then protect them selves from themselves ;). Now lets
consider the case where Joe Sixpack doesn't enable this and hardwires it to
"modern".

I come along and definetly want to use jikes - what choice do I have -
either modify the build file (yuck) or live with "modern" (double yuck) ;).

Now compare this to the current situation. Usually most projects include at
the top something like
  <!--
    Give user a chance to override without editing this file
    (and without typing -D each time he compiles it)
  -->
  <property file=".ant.properties"/>
  <property file="${user.home}/.ant.properties"/>

in which case I just drop a property file in relevent place to change
compiler. I have global properties set to use jikes so I am sweet and I am
good to go already.

Alternatively if they don't embed above snippet I can do a
-Dbuild.compiler=jikes on commandline. Another option that is no go if
compiler is specified as attribute.

>What does this mean?  Without any property over-rides, then the modern
>compiler is used.  If the "prop.compiler" property is over-ridden, (with
>"jikes" for example) then the jikes compiler is used ... all without the
>usage of magic properties!

naah it uses magic properties - just not implicit ones. Worse it means that
some projects may or may not provide the magic properties or may name them
different things ;(

>The ability to provide a classname for the
>compiler allows much more flexibility for users where the core supplied
>tasks don't meet their needs.

right - but I think we can do it better someother way ;)

>> What does everyone else think ?
>
>Does a vote for myself count, or is that implicit?  ;-)  You'll have to
>excuse my British cheek.  I blame my parents.

;)


Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message