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 Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language