ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: <script> and bsf
Date Tue, 10 Dec 2002 20:53:52 GMT
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"/>

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"

    <if><!-- Has buildmode already been set? -->
      <isset property="buildmode" />
        <echo message="WARNING: buildmode already set to: ${buildmode}" />

  </target><!-- buildmode -->

  <!-- ====================================================
       Selects building debug versions of all sub-projects.
  <target name="debug"
          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"
          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"

    <!-- 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 value="release">
        <property name="debug"         value="false" />
        <property name="configuration" value="Win32 Release" />
        <property name="baseconfig"    value="shared" />
        <fail message="Invalid buildmode: ${buildmode}" />

    <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! -->
        <equals arg1="${builmode}" arg2="release" />
        <istrue value="${}" />
      <then><property name="java.debug" value="false" /></then>
      <else><property name="java.debug" value="true"  /></else>

  </target><!-- ~set~config -->

-----Original Message-----
From: Costin Manolache [] 
Sent: Tuesday, December 10, 2002 2:01 PM
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.


> 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 []
> 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 []
> Sent: Tuesday, December 10, 2002 10:32 AM
> To:
> 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:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message