search

cps-org / cps

Common Package Specification — A cross-tool mechanism for locating software dependencies
https://cps-org.github.io/cps/
Other
108 stars 8 forks source link

How to represent header-only libraries #35

Open dcbaker opened 9 months ago

dcbaker commented 9 months ago

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

bretbrownjr commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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. :slightly_smiling_face: 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 commented 8 months ago

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 commented 8 months ago

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. :slightly_smiling_face: