Date: Wed, 27 Oct 2021 14:37:51 -0400
Include directory(ies) [-I flags], library directories [-L flags],
library names [-l flags] . Required preprocessor defines to be consistent
with the as-built binary.
What C++ features were used in the pre-built library, particularly needed
if we share dependencies. Library polyfills and alternatives are a problem
here. For example, boost.json can use std:: types if they are available, or
use boost components. A consumer needs to match. The feature test macros
might be a tool to expose those.
Names of dependencies to get from the package manager, so I can get their
flags and usage.
On Wed, Oct 27, 2021 at 2:06 PM Ben Craig via SG15 <sg15_at_[hidden]>
wrote:
> How do I invoke your code generator (like with gRPC, Apache Thrift,
> Microsoft RPC, QT)? How do I deal with dependencies with your code
> generator?
>
>
>
> What preprocessor flags and linker flags do I need to set to consume your
> library? What configuration options are there?
>
>
>
> What restrictions are your libraries placing on my binary? For example,
> am I required to use a static CRT to consume your library? A particular
> compiler version?
>
>
>
> *From:* SG15 <sg15-bounces_at_[hidden]> *On Behalf Of *Daniel Ruoso
> via SG15
> *Sent:* Wednesday, October 27, 2021 11:09 AM
> *To:* sg15_at_[hidden]
> *Cc:* Daniel Ruoso <daniel_at_[hidden]>
> *Subject:* [EXTERNAL] [SG15] RFC: Requirements to consume a prebuilt
> library from arbitrary build systems
>
>
>
> Hello,
>
> Thanks to the opportunity of being on site for cppcon (yay), me, Bret,
> Gabriel and Cameron had an opportunity to talk about the direction we're
> going for how to distribute libraries with C++ modules.
>
>
>
> In that conversation we got to an agreement that we should also explore
> the possibility of making this a solution that is not exclusive for
> modules, and take a step back for a more generic solution.
>
>
>
> I'm volunteering to drive the coordination work for a paper framing the
> requirements for a specification that would allow package managers and
> build systems to communicate on how to consume a prebuilt library.
>
>
>
> I should clarify up front that the goal here is not to specify the format
> of library packages, the mechanism to resolve versions and how to fetch the
> package. In fact, the goal is that this should be something that fills
> existing gaps in the interactions between different package managers and
> different build systems, hopefully allowing more interoperability amongst
> the players that are already in this space.
>
>
>
> So, I'm starting this effort with a request for comments on:
>
>
>
> What are things that your build system needs to know when consuming a
> prebuilt library? What are the non-obvious cases? What are the
> architecture-specific details?
>
>
>
> daniel
>
>
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
library names [-l flags] . Required preprocessor defines to be consistent
with the as-built binary.
What C++ features were used in the pre-built library, particularly needed
if we share dependencies. Library polyfills and alternatives are a problem
here. For example, boost.json can use std:: types if they are available, or
use boost components. A consumer needs to match. The feature test macros
might be a tool to expose those.
Names of dependencies to get from the package manager, so I can get their
flags and usage.
On Wed, Oct 27, 2021 at 2:06 PM Ben Craig via SG15 <sg15_at_[hidden]>
wrote:
> How do I invoke your code generator (like with gRPC, Apache Thrift,
> Microsoft RPC, QT)? How do I deal with dependencies with your code
> generator?
>
>
>
> What preprocessor flags and linker flags do I need to set to consume your
> library? What configuration options are there?
>
>
>
> What restrictions are your libraries placing on my binary? For example,
> am I required to use a static CRT to consume your library? A particular
> compiler version?
>
>
>
> *From:* SG15 <sg15-bounces_at_[hidden]> *On Behalf Of *Daniel Ruoso
> via SG15
> *Sent:* Wednesday, October 27, 2021 11:09 AM
> *To:* sg15_at_[hidden]
> *Cc:* Daniel Ruoso <daniel_at_[hidden]>
> *Subject:* [EXTERNAL] [SG15] RFC: Requirements to consume a prebuilt
> library from arbitrary build systems
>
>
>
> Hello,
>
> Thanks to the opportunity of being on site for cppcon (yay), me, Bret,
> Gabriel and Cameron had an opportunity to talk about the direction we're
> going for how to distribute libraries with C++ modules.
>
>
>
> In that conversation we got to an agreement that we should also explore
> the possibility of making this a solution that is not exclusive for
> modules, and take a step back for a more generic solution.
>
>
>
> I'm volunteering to drive the coordination work for a paper framing the
> requirements for a specification that would allow package managers and
> build systems to communicate on how to consume a prebuilt library.
>
>
>
> I should clarify up front that the goal here is not to specify the format
> of library packages, the mechanism to resolve versions and how to fetch the
> package. In fact, the goal is that this should be something that fills
> existing gaps in the interactions between different package managers and
> different build systems, hopefully allowing more interoperability amongst
> the players that are already in this space.
>
>
>
> So, I'm starting this effort with a request for comments on:
>
>
>
> What are things that your build system needs to know when consuming a
> prebuilt library? What are the non-obvious cases? What are the
> architecture-specific details?
>
>
>
> daniel
>
>
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2021-10-27 13:38:06