Date: Wed, 27 Oct 2021 19:52:35 +0000
> In other words, knowing how to provide proper inputs (including arguments) to the tool is a domain-specific problem that we can't reasonably expect to solve.
Yes, in Spack we leave this to packages — their build systems need to know how to run executables and we don’t expect the tool to know how to do that, at least not from just the metadata about the artifact.
> Given appropriate inputs, however, encoding the knowledge necessary to successfully *launch* the tool, however, may be in scope.
This should be in scope. Note that for x-compile scenarios, the architecture of bundled tools (which run in the build env) may be different from the architecture of the libraries (which are used in the run env). Or, you may need to have two versions of the thing (one for the build environment and one for the run environment), and there may be constraints to adhere to like “they need to be the same version”.
-Todd
> On Oct 27, 2021, at 12:47 PM, Matthew Woehlke via SG15 <sg15_at_lists.isocpp.org> wrote:
>
> On 27/10/2021 15.24, Daniel Ruoso via SG15 wrote:
>> On Wed, Oct 27, 2021, 12:06 Ben Craig <ben.craig_at_ni.com> 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?
>> That's an interesting borderline topic.
>> There's a line to be drawn between consuming libraries and describing how
>> tools are used.
>
> Indeed, and "how do I invoke your code generator" may be unsolvable, unless by "invoke" you are only speaking of run-time environment requirements. In other words, knowing how to provide proper inputs (including arguments) to the tool is a domain-specific problem that we can't reasonably expect to solve. Given appropriate inputs, however, encoding the knowledge necessary to successfully *launch* the tool, however, may be in scope. (As in, path to the tool, and if it needs any tool-specific environment variables set. Ideally with some level of abstraction such as 'set the LD_LIBRARY_PATH equivalent to the path of this other library target'.)
>
> --
> Matthew
> _______________________________________________
> SG15 mailing list
> SG15_at_lists.isocpp.org
> https://urldefense.us/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/sg15__;!!G2kpM7uM-TzIFchu!ksj0XcAABRPq40LdTebwcHcLp2bkjT99JkbaYEcoCrf-poTEuawUQ6sQME-x0gsdOA$
Yes, in Spack we leave this to packages — their build systems need to know how to run executables and we don’t expect the tool to know how to do that, at least not from just the metadata about the artifact.
> Given appropriate inputs, however, encoding the knowledge necessary to successfully *launch* the tool, however, may be in scope.
This should be in scope. Note that for x-compile scenarios, the architecture of bundled tools (which run in the build env) may be different from the architecture of the libraries (which are used in the run env). Or, you may need to have two versions of the thing (one for the build environment and one for the run environment), and there may be constraints to adhere to like “they need to be the same version”.
-Todd
> On Oct 27, 2021, at 12:47 PM, Matthew Woehlke via SG15 <sg15_at_lists.isocpp.org> wrote:
>
> On 27/10/2021 15.24, Daniel Ruoso via SG15 wrote:
>> On Wed, Oct 27, 2021, 12:06 Ben Craig <ben.craig_at_ni.com> 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?
>> That's an interesting borderline topic.
>> There's a line to be drawn between consuming libraries and describing how
>> tools are used.
>
> Indeed, and "how do I invoke your code generator" may be unsolvable, unless by "invoke" you are only speaking of run-time environment requirements. In other words, knowing how to provide proper inputs (including arguments) to the tool is a domain-specific problem that we can't reasonably expect to solve. Given appropriate inputs, however, encoding the knowledge necessary to successfully *launch* the tool, however, may be in scope. (As in, path to the tool, and if it needs any tool-specific environment variables set. Ideally with some level of abstraction such as 'set the LD_LIBRARY_PATH equivalent to the path of this other library target'.)
>
> --
> Matthew
> _______________________________________________
> SG15 mailing list
> SG15_at_lists.isocpp.org
> https://urldefense.us/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/sg15__;!!G2kpM7uM-TzIFchu!ksj0XcAABRPq40LdTebwcHcLp2bkjT99JkbaYEcoCrf-poTEuawUQ6sQME-x0gsdOA$
Received on 2021-10-27 14:52:40