This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: [ECOS] Re: Bug in crc32 routine?
>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:
>> More out of interest than anything, CDL has an implies operator which
>> allows you to use:
>>
>> requires { (CYG_HAL_CPUTYPE == \"KS32C5000A\" ) implies CYGPKG_CRC }
>>
>> which is more readable.
Andrew> Yep, forgot about that.
Andrew> Although, in the past i've had problems with implies. I
Andrew> think implies implies the CDL conflict engine can modify
Andrew> these options to try to resolve the conflict. As you point
Andrew> out below, CYCPKG_CRC may not be know, so it may actually
Andrew> try to resolve this conflict by changing the CPUTYPE! This
Andrew> is all theoretical, i've not tried it.
The inference engine should treat
requires { A implies B }
in exactly the same way as
requires { !A || B }
so the constraint can be resolved by enabling B, disabling A, or
making A inactive. The "implies" operator does not have any special
meaning. It could also be written as
requires { B || !A }
Usually this will have the same effect, but if there is absolutely no
reason to prefer B or !A then the inference engine will always prefer
the right-hand branch of the logical or.
Theoretically, assuming both A and B are boolean options, the
constraint could also be written as:
requires { A <= B }
although I hope nobody would actually write CDL like that, and the
current inference engine does not try very hard when dealing with
inequalities.
Given
requires { CYGPKG_CRC || (!(CYG_HAL_CPUTYPE == \"KS32C5000A\")) }
or
requires { (CYG_HAL_CPUTYPE == \"KS32C50000A\") implies CYGPKG_CRC }
if CYGPKG_CRC is not loaded then the inference engine must either
change the cpu type, or it must make the cpu type irrelevant (i.e.
inactive), or it must make the containing option disabled or inactive.
Without autoloading, those are the possible solutions. Other
constraints should control which if any of these solutions are legal.
Bart