Those are all good starts. But the short answer, since I don't have time
ATM, for what you need to communicate to produce and consume prebuilt
libraries are:

* All the inputs that went into producing the library. This includes what's
been mentioned and also the environment (yes, as in ENV vars and everything
else) they were produced in that might affect the result.
* All the usage requirements for the library.
* The entire n-dimensional matrix of compiler flag ABI, and general
compatibility for the compilers in question.

It should be obvious that this is an NP complete problem to solve. And that
we will only get partial / good-enough solutions to. Just like we do for
dealing with ABI.

On Wed, Oct 27, 2021 at 1:38 PM Steve Downey via SG15 <sg15_at_[hidden]>
wrote:

> 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
>>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>

-- 
-- René Ferdinand Rivera Morell
-- Don't Assume Anything  -- No Supone Nada
-- Robot Dreams - http://robot-dreams.net