Date: Thu, 14 Feb 2019 12:10:08 -0500
On 14/02/2019 11.51, JF Bastien wrote:
> On Thu, Feb 14, 2019 at 8:42 AM Matthew Woehlke wrote:
>> ...then let a tool do it.
>>
>> Oh, look! You've invented a portable, intermediate representation!
>
> Invention requires novelty. Extracting a header from source isn't novel.
I think you missed the point... which was that, on one hand, you claim
we don't need a PMIR, while on the other hand explaining how to produce
exactly that (while seeming to not notice that's what you did).
>> On Wed, Feb 13, 2019 at 7:07 AM Ben Boeckel wrote:
>>>> For projects which don't build zlib++ (as a strawman) as part of their
>>>> build and instead assume that there is one provided by the system, yes.
>>>
>>> I don’t think that’s true, based on what my platform offers.
>>
>> What is shipped as the module interface? (Is that the same thing that
>> would be shipped in an IS-modules world?)
>
> Our paper covers how clang modules work. We use modules internally (not for
> every project), and we ship headers + binary for some frameworks.
Right. But we're also not copying clang-modules exactly. The objective
was to determine how things can work in an IS-modules world.
"Divide your sources into interface and implementation like today and
ship the interface sources" is a possible answer. I'm not sure if we
have consensus on it, however.
> Developers on our platform can use modules if they so desire. Some of our
> headers are massaged by a variety of tooling.
Right... so you have a tool-generated PMIR. Which happens to look like
headers.
>> Can it be used by every compiler?
>
> Depends what you mean by "it".
PMIR's a.k.a. "whatever packages ship that is portable and suitable for
either being imported directly or generating something which can be
imported, and need not include the implementation sources".
> Headers and linking work just fine. I also don't think this is
> relevant.
"Can I use modules without shipping in source form?" seems relevant.
> You should probably talk to Bruno in Kona. I think this would help
> demystify things even more that what we've tried with our paper.
Alas, I won't be at Kona.
> On Thu, Feb 14, 2019 at 8:42 AM Matthew Woehlke wrote:
>> ...then let a tool do it.
>>
>> Oh, look! You've invented a portable, intermediate representation!
>
> Invention requires novelty. Extracting a header from source isn't novel.
I think you missed the point... which was that, on one hand, you claim
we don't need a PMIR, while on the other hand explaining how to produce
exactly that (while seeming to not notice that's what you did).
>> On Wed, Feb 13, 2019 at 7:07 AM Ben Boeckel wrote:
>>>> For projects which don't build zlib++ (as a strawman) as part of their
>>>> build and instead assume that there is one provided by the system, yes.
>>>
>>> I don’t think that’s true, based on what my platform offers.
>>
>> What is shipped as the module interface? (Is that the same thing that
>> would be shipped in an IS-modules world?)
>
> Our paper covers how clang modules work. We use modules internally (not for
> every project), and we ship headers + binary for some frameworks.
Right. But we're also not copying clang-modules exactly. The objective
was to determine how things can work in an IS-modules world.
"Divide your sources into interface and implementation like today and
ship the interface sources" is a possible answer. I'm not sure if we
have consensus on it, however.
> Developers on our platform can use modules if they so desire. Some of our
> headers are massaged by a variety of tooling.
Right... so you have a tool-generated PMIR. Which happens to look like
headers.
>> Can it be used by every compiler?
>
> Depends what you mean by "it".
PMIR's a.k.a. "whatever packages ship that is portable and suitable for
either being imported directly or generating something which can be
imported, and need not include the implementation sources".
> Headers and linking work just fine. I also don't think this is
> relevant.
"Can I use modules without shipping in source form?" seems relevant.
> You should probably talk to Bruno in Kona. I think this would help
> demystify things even more that what we've tried with our paper.
Alas, I won't be at Kona.
-- Matthew
Received on 2019-02-14 18:10:10