HPX module "configurations"

[msimberg]

This issue is for discussing if and how to expose modules to users:

• size of modules; small and large?
• static/dynamic?
• build configurations?

[msimberg]

There are a few high-level "natural" levels of features that build on top of each other:

• utilities (testing, assertions, configuration, etc.)
• thread pools only
• synchronization primitives/futures (manual thread pool management, explicitly pass executors to apply/async)
• parallel algorithms
• local runtime (configuration management, default pool for apply/async)
• distributed runtime (including support for components/actions)
• distributed synchronization primitives, collectives
• distributed parallel algorithms
• optional components (already linked separately)

In addition to this users may want to pick smaller modules individually (hpx_concurrency). The question is: can we support both use cases? Can we support both use cases simultaneously (can I link to libhpx_threading ("high-level" module) and libhpx_serialization ("low-level" module)? Is the distinction necessary? Allowing mixing libraries like this increases the risk of duplicate symbols (at least with our current setup).

How do we handle build configurations? Should it be possible to individually disable modules? Is it up to the user to ensure that a module's dependencies are all enabled?

Given how complex things could get I'm leaning towards only exposing these "high-level" configurations/libraries to the user.

That's more questions than answers and should get us started...

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.