ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: <script> and bsf
Date Tue, 10 Dec 2002 21:40:30 GMT
Me neither. I thought you said you wanted to 'fix' "properties and
references set by the first target are visible to the second target on the
command line", i.e. make them non-visible to the second target.

I'm all for "ant a b" executing common,a,b - That's what I always wanted ;-)

I realize just now that if you meant to 'fix' "ant a b" so it executes
common,a,b, then of course the properties/references are visible... Thus the
mis-understanding I guess!?!?!? --DD

-----Original Message-----
From: Costin Manolache [mailto:cmanolache@yahoo.com] 
Sent: Tuesday, December 10, 2002 3:21 PM
To: ant-dev@jakarta.apache.org
Subject: RE: <script> and bsf

I still don't understand, sorry...

Your case doesn't even have duplicated targets - so it has nothing 
to do with the change that eliminates the duplicated targets.

The issue is: if you have 
<target name="a" depends="common" />
<target name="b" depends="common" />
<target name="common" >
  <echo>Test</echo>
</target>

and you call "ant a b", then ant should execute common,a,b - and
not common,common,a,b ( i.e. you should see only one "Test" message )
Properties are imuttable - so if you use this for configuration
it doesn't matter if "common" is executed once or twice ( or n times ).


It is not a big deal IMO - if there is a good use case or we find
at least someone who uses the multiple execution of the common target
then we should keep it this way ( and make it clear this is the 
intended behavior and what's the use case where it helps ).

The question is if this features affects the delayed evaluation
and the top-level execution. I don't think so ( at least not
compared with 1.5 where top-level tasks were not permitted ).
 
Costin


Dominique Devienne wrote:

> Here's my use case:
> 
> ant debug build
> 
> Target 'build' depends on target '-set-config' (shown below).
> Target 'debug' simply sets (is an alias for) -Dbuildmode=debug, which is
> used by '-set-config', when called as a dependent of 'build', to set other
> properties. (I could also have set all the properties debug /
> configuration / baseconfig / config in the 'debug' target directly.)
> 
> Another use case from another build is to skip testing (saves a lot of
> -Dname=value typing):
> 
>   <!-- ===================================================================
> -->
>   <!-- Set all the properties for skipping tests. This is just to make it
> -->
>   <!-- a bit easier to skip tests when doing a build.
> -->
>   <!-- EXAMPLE: build notests build jars
> -->
>   <!-- ===================================================================
> -->
>   <target name="notests"
>           description="Sets properties to skip ALL tests on this build">
>     <echo message="ALL tests have been disabled for this build"/>
>     <property name="no-unit-tests" value="true"/>
>     <property name="no-gui-tests" value="true"/>
>     <property name="no-example-tests" value="true"/>
>     <property name="no-ow-tests" value="true"/>
>     <property name="no-sw-tests" value="true"/>
>     <property name="no-ow_gocad-tests" value="true"/>
>   </target>
> 
> Maybe not the best examples, but changing this behavior would break these
> two examples. --DD
> 
> 
>   <!-- ====================================================
>        Check whether the build mode has already been set,
>        and warn the user as such, saying the target is ignored.
>     -->
>   <target name="-check-buildmode"
>           depends="-ant-contrib-defs">
> 
>     <if><!-- Has buildmode already been set? -->
>       <isset property="buildmode" />
>       <then>
>         <echo message="WARNING: buildmode already set to: ${buildmode}" />
>       </then>
>     </if>
> 
>   </target><!-- buildmode -->
> 
>   <!-- ====================================================
>        Selects building debug versions of all sub-projects.
>     -->
>   <target name="debug"
>           depends="-check-buildmode"
>           description="Specifies Debug build mode (-Dbuildmode=debug).">
> 
>     <property name="buildmode" value="debug" />
> 
>   </target><!-- debug -->
> 
>   <!-- ====================================================
>        Selects building release versions of all sub-projects.
>     -->
>   <target name="release"
>           depends="-check-buildmode"
>           description="Specifies Release build mode
>           (-Dbuildmode=release).">
> 
>     <property name="buildmode" value="release" />
> 
>   </target><!-- release -->
> 
>   <!-- ====================================================
>        Selects building release versions of all sub-projects.
>     -->
>   <target name="-set-config"
>           depends="-ant-contrib-defs">
> 
>     <!-- Default to a release build -->
>     <property name="buildmode" value="release" />
> 
>     <!-- Set various properties according to the build mode -->
>     <switch value="${buildmode}" caseinsensitive="true">
>       <case value="debug">
>         <property name="debug"         value="true" />
>         <property name="configuration" value="Win32 Debug" />
>         <property name="baseconfig"    value="shared.debug" />
>       </case>
>       <case value="release">
>         <property name="debug"         value="false" />
>         <property name="configuration" value="Win32 Release" />
>         <property name="baseconfig"    value="shared" />
>       </case>
>       <default>
>         <fail message="Invalid buildmode: ${buildmode}" />
>       </default>
>     </switch>
> 
>     <property name="config" value="win32-i86-msvc.${baseconfig}" />
> 
>     <!-- In all build modes, we always want to compile Java code
>          in debug mode, to have line numbers in stack traces,
>          unless explicitly told not to, with the Xyz property! -->
>     <if>
>       <and>
>         <equals arg1="${builmode}" arg2="release" />
>         <istrue value="${compile.java.code.without.debug.info}" />
>       </and>
>       <then><property name="java.debug" value="false" /></then>
>       <else><property name="java.debug" value="true"  /></else>
>     </if>
> 
>   </target><!-- ~set~config -->
> 
> -----Original Message-----
> From: Costin Manolache [mailto:cmanolache@yahoo.com]
> Sent: Tuesday, December 10, 2002 2:01 PM
> To: ant-dev@jakarta.apache.org
> Subject: RE: <script> and bsf
> 
> Dominique Devienne wrote:
> 
>> I agree with you Alexey. Even if the current behavior seems weird, it's
>> Ant behavior, which many people take advantage of, including me, to
>> create 'property setting' targets (properties used by other targets
>> specified on the command line). I don't want that behavior to go away
>> (that would be a clear regression, which I don't expect from Costin).
> 
> So you rely on the common targets being executed twice ?
> 
> How will that affect the property setting targets ?
> 
> I have no problem with keeping this behavior - and if people relly
> on it then it may even be usefull :-)
> 
> Probably documenting it clearly is the best solution ( including the use
> case you describe - so people who don't get it, like me, can use it )
> 
> Regarding comma-separated targets - sounds good, but I would like to
> know the use case. I don't feel very well about adding much logic to
> the command line - and I'm not sure how this will affect the API.
> 
> Costin
> 
>> 
>> I like Alexey's idea of comma-separating targets names on the command
>> line to have the pseudo-target behavior, similar to the current 'depend'
>> attribute of <target>. --DD
>> 
>> -----Original Message-----
>> From: Alexey Solofnenko [mailto:A.Solofnenko@mdl.com]
>> Sent: Tuesday, December 10, 2002 12:55 PM
>> To: 'Ant Developers List'
>> Subject: RE: <script> and bsf
>> 
>> It is a feature, but many people would like to have it implemented
>> differently. Without breaking existing functionality I think it is
>> possible to add "ANT A,B" syntax to execute A and B without reexecuting
>> common targets, by creating a temporary pseudo target that depends from A
>> and B and executing it.
>> 
>> - Alexey.
>> 
>> -----Original Message-----
>> From: Costin Manolache [mailto:cmanolache@yahoo.com]
>> Sent: Tuesday, December 10, 2002 10:32 AM
>> To: ant-dev@jakarta.apache.org
>> Subject: Re: <script> and bsf
>> 
>> Stefan Bodewig wrote:
>> 
>>>> - should "ant A B" behave like "ant A; ant B" or remove duplicated
>>>> targets ?
>>> 
>>> It does neither of both.  It will execute common targets twice (so
>>> it's close to ant A; ant B), but properties set during the first pass
>>> will keep their value in the second pass - same for references.
>> 
>> That sounds like a clear bug that needs to be fixed.
>>  
>> ...
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>




--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message