gobo-eiffel-develop

[gobo-eiffel-develop] geant task 'geant' can now handle execution result

[Sven E. <sve...@we...>]

As requested the task 'geant' now is able to handle (or ignore) the
execution result by specifying the attribute 'exit_code_variable' (as it is done in task 'exec').

To ignore the result (e.g. for running several unittests) use it like this for example:

  ...
  <geant file="build.eant" target="${target}" dir="argument" exit_code_variable="dummy"/>
  ...

Having introduced an artificial bug in one of the tests for the argument library to test
the new behavior the output looks as follows:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...

# PASSED:     531 tests
# Failed:     0 test
# Aborted:    0 test
# Total:      531 tests (1836 assertions)

Testing xargument...
Preparing Test Cases
Compiling Test Cases
Running Test Cases

Test Summary for xargument

# Passed:     12 tests
# FAILED:     1 test
# Aborted:    0 test
# Total:      13 tests (74 assertions)

Test Results:
FAIL:  [AP_TEST_PARSER.test_make] has_no_options_in_basic
   expected: 9
   but  got: 0

BUILD FAILED!

Testing xlexical...
Preparing Test Cases
Compiling Test Cases
Running Test Cases

...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As you can see there still is a BUILD FAILED message but the script continues it's
execution.

- Sven

Re: [gobo-eiffel-develop] geant task 'geant' can now handle execution result

[Jocelyn <li...@dj...>]

Hi,

This addition will be appreciated :)

I was wondering, what about the
    accept_errors="true|false" 

It seems to be required when used with nested fileset, I think task 
geant can be used with nested fileset too
however I don't really see the point of having "exit_code_variable" and 
"accept_errors"
Can't we just have "exit_code_variable"  ?

What about tasks  copy, move, delete, mkdir, .. ?
I think we can always encapsulate such calls in "target", this was we 
use the exit_code_variable as a kind of "rescue"

-- Jocelyn

On 2/10/2008 22:01 PM, Sven Ehrke wrote:
> As requested the task 'geant' now is able to handle (or ignore) the
> execution result by specifying the attribute 'exit_code_variable' (as it is done in task 'exec').
>
> To ignore the result (e.g. for running several unittests) use it like this for example:
>
>   ...
>   <geant file="build.eant" target="${target}" dir="argument" exit_code_variable="dummy"/>
>   ...
>
> Having introduced an artificial bug in one of the tests for the argument library to test
> the new behavior the output looks as follows:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ...
>
> # PASSED:     531 tests
> # Failed:     0 test
> # Aborted:    0 test
> # Total:      531 tests (1836 assertions)
>
> Testing xargument...
> Preparing Test Cases
> Compiling Test Cases
> Running Test Cases
>
> Test Summary for xargument
>
> # Passed:     12 tests
> # FAILED:     1 test
> # Aborted:    0 test
> # Total:      13 tests (74 assertions)
>
> Test Results:
> FAIL:  [AP_TEST_PARSER.test_make] has_no_options_in_basic
>    expected: 9
>    but  got: 0
>
> BUILD FAILED!
>
> Testing xlexical...
> Preparing Test Cases
> Compiling Test Cases
> Running Test Cases
>
> ...
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> As you can see there still is a BUILD FAILED message but the script continues it's
> execution.
>
> - Sven
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
>
>   

Re: [gobo-eiffel-develop] geant task 'geant' can now handle execution result

[Sven E. <sve...@we...>]

Jocelyn wrote:

> I was wondering, what about the
>    accept_errors="true|false"
> It seems to be required when used with nested fileset, I think task
> geant can be used with nested fileset too
> however I don't really see the point of having "exit_code_variable" and
> "accept_errors"
> Can't we just have "exit_code_variable"  ?

Yes, 'exit_code_variable' should be sufficient and that is the reason
why I did not implement 'accept_errors' (it is obsolete in <exec> for exactly
that reason).
When nested filesets are used it gets more difficult. When you
look into the documentation of the <exec> task it says for 'exit_code_variable':

  ...this attribute can only be used when no fileset is used as nested argument

and for 'accept_errors'

  ...Use this attribute only if a nested fileset is specified...

'accept_erros' can work with filesets since one cannot query the
exit code anyway so non-zero exit codes will simply be ignored and the loop
will be continued.

With 'exit_code_variable' it is more complicated though:
should the first non-zero exit code iteration abort the loop or continue?
I don't know and that is the reason this attribute is not supported when
nested filesets are used. But maybe someone has a good idea on what to do
in this situation?
One possibility I can think of is supporting 'exit_code_variable' also for
filesets and setting it to the last (or first?) non-zero result of an iteration
(and if no iteration fails it would be set to zero of course).

- Sven


> 
> What about tasks  copy, move, delete, mkdir, .. ?
> I think we can always encapsulate such calls in "target", this was we
> use the exit_code_variable as a kind of "rescue"
> 
> -- Jocelyn
> 
> On 2/10/2008 22:01 PM, Sven Ehrke wrote:
>> As requested the task 'geant' now is able to handle (or ignore) the
>> execution result by specifying the attribute 'exit_code_variable' (as
>> it is done in task 'exec').
>>
>> To ignore the result (e.g. for running several unittests) use it like
>> this for example:
>>
>>   ...
>>   <geant file="build.eant" target="${target}" dir="argument"
>> exit_code_variable="dummy"/>
>>   ...
>>
>> Having introduced an artificial bug in one of the tests for the
>> argument library to test
>> the new behavior the output looks as follows:
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> ...
>>
>> # PASSED:     531 tests
>> # Failed:     0 test
>> # Aborted:    0 test
>> # Total:      531 tests (1836 assertions)
>>
>> Testing xargument...
>> Preparing Test Cases
>> Compiling Test Cases
>> Running Test Cases
>>
>> Test Summary for xargument
>>
>> # Passed:     12 tests
>> # FAILED:     1 test
>> # Aborted:    0 test
>> # Total:      13 tests (74 assertions)
>>
>> Test Results:
>> FAIL:  [AP_TEST_PARSER.test_make] has_no_options_in_basic
>>    expected: 9
>>    but  got: 0
>>
>> BUILD FAILED!
>>
>> Testing xlexical...
>> Preparing Test Cases
>> Compiling Test Cases
>> Running Test Cases
>>
>> ...
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>> As you can see there still is a BUILD FAILED message but the script
>> continues it's
>> execution.
>>
>> - Sven
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> gobo-eiffel-develop mailing list
>> gob...@li...
>> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>>
>>
>>   
> 
> 
>