The main objective of this PR is to provide a solution to:
- Compile all the runtime supports within a single build if needed
- Possibly enable dynamic runtime selection during the library initialization as mentioned in #11 (The target here is not to provide multi-runtime support in the same execution)
In order to provide the best solution that suits the needs of everyone, a repository has been set up with multiple examples of what could be done: https://gitlab.inria.fr/faverge/test-multi-runtime
This repository includes a template directory that aims at reproducing the Chameleon code structure. This directory should not be modified, unless we realize it does not match closely enough the real case.
The README of this repository describes the different solutions proposed to solve this problem. With an attempt to discuss pros and cons, and sometimes with some limitation that are not fixed yet.
Please, anyone who has any ideas we have missed, solutions to ongoing problems, or whatever it is that is related to the subject. Don't hesitate to comment, ask questions, or suggest solutions.
When we will have converge on a common solution that everyone agree with. We will apply the changes to Chameleon within this PR to validate it.
The following paragraph is just here to keep a track
* One build allows to use one of the 4 `chameleon_xxxx` runtime libraries (openmp, parsec, quark, starpu) at runtime.
This is done with the dlopen mechanism because the runtime interface libraries are not always located in the same directory (build dir vs. install dir ? system path vs. local path ? etc) it is difficult to guess where to take them. As a result we ask user to give the library path with the environment variable CHAMELEON_RUNTIME_LIBRARY.
* if several runtimes are enabled we force to build chameleon shared (dynamic) libraries
* gitlab-ci jobs have been updated
* Doc has been updated
- discuss how we choose the scheduler at runtime
- with a specific environment variable such as CHAMELEON_RUNTIME_LIBRARY (current implementation)
- with an executable option -> we need to set chamctxt->scheduler before the call to RUNTIME_context_create
- update the documentation depending on 1)