Proposal: project kind 'HeaderOnly' for header only libs

[KageKirin]

Hi,

I'd like to add the project kind 'HeaderOnly' for header only libs, i.e. libs for which I want a VS/Xcode project so they appear cleanly in the IDE, but that do not 'build' per se, i.e. no compile/link/ar instructions.

My main motivation is to remove AR warnings with make/ninja files, and possibly linker errors.

What do you think? It's not that much to change, but the addition of this feature is likely to affect all target build types.

Cheers.

[bkaradzic]

What are current warnings you're getting? Empty .a file?

[KageKirin]

E.g. from my current build

==== Building cgltf (debug) ====
Archiving cgltf
ar: no archive members specified
usage:  ar -d [-TLsv] archive file ...
        ar -m [-TLsv] archive file ...
        ar -m [-abiTLsv] position archive file ...
        ar -p [-TLsv] archive [file ...]
        ar -q [-cTLsv] archive file ...
        ar -r [-cuTLsv] archive file ...
        ar -r [-abciuTLsv] position archive file ...
        ar -t [-TLsv] archive [file ...]
        ar -x [-ouTLsv] archive [file ...]
==== Building cxxopts (debug) ====
Archiving cxxopts
ar: no archive members specified
usage:  ar -d [-TLsv] archive file ...
        ar -m [-TLsv] archive file ...
        ar -m [-abiTLsv] position archive file ...
        ar -p [-TLsv] archive [file ...]
        ar -q [-cTLsv] archive file ...
        ar -r [-cuTLsv] archive file ...
        ar -r [-abciuTLsv] position archive file ...
        ar -t [-TLsv] archive [file ...]
        ar -x [-ouTLsv] archive [file ...]

cgltf and cxxopts are header only libs.

One of my workarounds is to just have static void foobar(){} in a C file compiled along the headers, but not requiring to do this would be more elegant.

---

EDIT:
Reason for this: $(LINKOBJS) resolves to $(OBJECTS) which is empty since nothing is compiled to produce objects, hence being empty at the linker invocation.

$(LINKCMD) $(LINKOBJS)

[bkaradzic]

So basically you would need to identify project that doesn't have any buildable files, and then remove it completely from archiving, and linking.

[KageKirin]

And from being added as link dependency to other projects, yes.

I still think making it explicit through the project type is more elegant, but I got your point about just fixing the existing behavior to be correct.
IMHO, both are valid approaches. Which one do you prefer?

[bkaradzic]

Which one do you prefer?

Fixing existing behaviour, so that just works without adding anything.

As first step you could add generation of dummy file automatically when you detect that there are no buildable files. And then implement it correctly. I'm proposing two step process because 2nd step might be too risky and we could back out to previous state in case of some major issues.

[KageKirin]

You mean, generating a .c, respectively .cpp file, containing a simple static void libname_dummy(){} ?

Sounds feasible. I'll start adding this to gmake and ninja to see how it works out in practice.

[KageKirin]

@bkaradzic
My PR #491 seems like an easily feasible approach? What do you think?
I still have to verify I didn't break anything with VS and other generators I haven't touched on that branch, but if you could confirm that you like the direction I'm taking there, I'll do all the necessary checking.

(I'm on New Year's break from the 28th until around the 10th of January, so I still have next week do do those checks).