How to represent header-only libraries

[dcbaker]

It seems odd to call them an Interface, but there doesn't seem to be another way to represent them

[bretbrownjr]

That's how CMake models header-only libraries for what it's worth.

I suppose it's possible for CPS to have a Header-Only type just for clarity reasons.

I think more interestingly, I'd like to see #18 looked at so that it's more clear what a header-only library actually is. Right now, most build systems treat it as a header include directory and let the compiler worry about how headers interrelate with other things.

I think end users (C++ programmers) could use a lot more support, and I think that requires modelling that header-only libraries actually consist of specific headers that have designed APIs. For instance, there would need to be metadata to steer users away from including a "private" bits/whatever.h. The compiler won't care and the build system doesn't really see the problem either way.

[mwoehlke]

The interface type is the intended mechanism. I'm not necessarily wedded to the name, but I don't have any better ideas.

In general, the idea of a component specification is 'you need to do X, Y and Z' to use me, where those possible things are 'also use another component', 'link this artifact', 'use these compile definitions', etc. At minimum, in a C-like world, possible target types are stand-alone executable, shared library, static library, and no binary (link) artifact. A header-only library is the last. Right now the canonical name for that is interface.

[dcbaker]

Okay. Conceptually "Interface" sounds more to me like "We renamed this component, and this 'Interface' maintains backwards compat" or "we have 100 implementation details but 10 supported 'Interfaces'", which sound pretty useful (LLVM has some of these "convenience" targets that just bundle up many implementation libraries)

[mwoehlke]

Conceptually "Interface" sounds more to me like "We renamed this component, and this 'Interface' maintains backwards compat" or "we have 100 implementation details but 10 supported 'Interfaces'", which sound pretty useful

Well, to be fair, those are also use cases for interface components. 🙂 It just happens that, on a technical level, the machinery for those is also perfectly suited to header-only libraries. Now, if we want to get into a discussion whether it's less confusing to make those separate types, I suppose we could do that...

[dcbaker]

I think it would be useful to enumerate some of the common uses we envision for "interfaces"; or to mention that header-only libraries would be represented by "interfaces".

[mwoehlke]

I think it would be useful to enumerate some of the common uses we envision for "interfaces"; or to mention that header-only libraries would be represented by "interfaces".

That sounds like a reasonable action item; if not in the spec itself, then at least in the supporting 'tutorial' material we really need to get working on. 🙂