On Thu, Feb 14, 2019 at 8:42 AM Matthew Woehlke <mwoehlke.floss_at_[hidden]>
wrote:

> On 13/02/2019 10.26, JF Bastien wrote:
> > On Wed, Feb 13, 2019 at 7:07 AM Ben Boeckel wrote:
> >> On Tue, Feb 12, 2019 at 14:01:34 -0800, JF Bastien wrote:
> >>> I'm confused as to why headers suddenly stop working.
> >>
> >> Because if, as a project, I port over to modules, I *still* have to
> >> maintain headers? I may as well not do modules at all at that point just
> >> due to maintenance costs.
> >
> > Seems something a tool can do, if I understand what you have in mind.
>
> ...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.


(Note on possible point of confusion: "intermediate representation" as I
> am using it should not be assumed to have any relation to "IR" in
> current compiler parlance. It means only what it literally means;
> something which exists between the original user-authored source files
> and BMI's.)
>
> Modules won't work unless we retain having separate files for the
> interface (what is externally consumed) and implementation (what is not
> distributed). Neither shipping the complete source code nor shipping
> just BMI's are feasible options for at least some audiences.
>
> As previously stated, I was under the impression that some people felt
> strongly that one of their 'goals for modules' was to be able to get rid
> of that distinction at the managed-source level (i.e. the files that are
> developer-authored would not make such a distinction). If that is indeed
> a goal, then we *must* have a PMIR¹. I'm not sure what form that will
> take; it *may* look suspiciously like a C++ "header" file that is
> automatically generated by the compiler.
>
> AFAICT, the only plausible alternative is to require folks to maintain
> the interface/implementation split in their original sources, and to
> continue to ship the inteface source files. Which... is basically what
> we do today, and contradicts something I had understood to be a desired
> goal of modules. I'm okay with that, but if that's the case, let's
> please state that clearly.
>
> (¹ Portable Module Interface Representation)
>
> >> 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.
Developers on our platform can use modules if they so desire. Some of our
headers are massaged by a variety of tooling.



> Can it be used by every
> compiler?


Depends what you mean by "it". Headers and linking work just fine. I also
don't think this is relevant.


What does the developer need to do to create/maintain said
> artifacts?
>

Modularization requires work, and there are some tools that try to help.
Once you've modularized, there's no unusual amounts of work required.

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.



> --
> Matthew
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>