这是indexloc提供的服务,不要输入任何密码
Skip to content

To Be Header-Only or Not to Be? #1540

@solarispika

Description

@solarispika

I'm exploring the stdexec project and have noticed an inconsistency between its description as a header-only library and the handling of the system_context binary in the Conan package.

The README states: "This library is header-only, so all the source code can be found in the include/ directory." However, the system_context library, defined in CMakeLists.txt and built from src/system_context/system_context.cpp, is a compiled binary, not header-only. This is confirmed by Issue #1477, where a user resolved a linking error by explicitly linking to system_context when using exec::get_system_scheduler().

The Conan recipe (conanfile.py) includes system_context in the package and specifies it as a required library (self.cpp_info.libs = ["system_context"]). However, it also clears the package ID (self.info.clear()), treating the package as header-only. This creates a potential issue: since system_context is a platform-specific binary, using the same package ID across different platforms and compilers could lead to compatibility problems (e.g., using a Windows-built system_context binary on Linux or macOS).

Could the maintainers clarify:

  1. Is stdexec intended to be fully header-only, or should the documentation reflect that system_context is a required binary component?
  2. Should the Conan recipe remove self.info.clear() to ensure platform-specific package IDs for the system_context binary, avoiding potential cross-platform compatibility issues?

Thank you for maintaining this project and for any clarification you can provide!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions