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
>>
>>
>>   
> 
> 
>