A problem arose some time ago, that some library code required async
support (flx_arun driver),
and some needed SDL support (flx_sdl_run driver), and some needed both
(say, flx_sdl_arun
driver).
The problem is of course that ordinary code needing async support
can't know other code
needed SDL support .. but there is no way with a "target" based
resource tree that
two independent resources requirements can be satisfied by one entity.
A related example: some code need library A, other code library B, and
A and B require
each other. You'd like to make library A+B to avoid dynamic linkage
overheads on
calls between these libraries (indeed you may get inlining of some
calls).
But whilst a simple requires clause can expand to multiple
requirements (virtual targets),
there's no way to *combine* requirements:
Library A+B satisfies the need for both A and for B.
This is also what we need for the first case: a driver that supports
both async and SDL.
A solution is to add a field:
subsumes: A, B
to the *.fpc file for the combined entity A+B, and then scan all the
*.fpc files
to build a subsumption tree. This just the dual of a dependency tree.
Given arrows pointing from a resource set to a containing (subsuming)
resource set, a requirement for a resource "driver" value "A" and also
value "B" can be satisfied by the smallest containing resource "driver"
which subsumes A and subsumes B (directly or indirectly).
The library and driver cases are different though: if you don't find
A+B, then A and B can both be loaded, whereas you can only have
one driver and so drivers all conflict and finding a subsuming entity
is mandatory.
As tempting as it may be to add a "conficts" field, this does NOT work.
This is because of the open/close principle: you have A and make
a conficting A+ entity, A+ conflicts with A, which you specify.
But A conflicts with A+ too, and you can't change the descriptor of A
(because it is closed).
For the driver this can be fixed with a "Unique_value: DRIVER"
field, so that if two entities have the same unique value, a third
entity subsuming both (presumably having the same unique value
field) must be found. But these seems rather restricted. A global
scan would allow unilateral specification of mutual conflicts,
but global scans are ugly .. although 'subsumes' seems to
require that anyhow?
Hmm .. anyhow a germ of a solution ..
--
john skaller
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
