Gradle Sample header-only-library

[Brenne]

I have a question / suggestion regarding the the header-only-library sample:

My understanding: a header only library has just headers - no .cpp source files. Applying the plugin of the current sample on a header only library will result that as an build output a static library is produced as well as a dummy cpp source file is compiled (if I understand the sample correctly both steps are a workaround). Other libraries that consume this header only library will add the static library to their link options (no harm but this doesn't seem clean to me).

I have the following suggestion, here just in Kotlin Script Syntax:

plugins {
    `cpp-library`
}

library {
    linkage.set(listOf(Linkage.STATIC))
}

components.withType<CppStaticLibrary>().configureEach {
    val outgoingArtifacts = linkElements.get().outgoing
    outgoingArtifacts.artifacts.removeIf {
        it.file == linkFile.get().asFile
    }
}

tasks.withType<CreateStaticLibrary>().configureEach {
    enabled = false
}

tasks.withType<CppCompile>().configureEach {
    enabled = false
}

I'm happy to contribute a PR to the native-samples repo if this suggestion finds support. I tested the suggestion with consuming projects (using project path as well as published dependencies) building works. The benefits:

• no dummy source necessary
• time saved: no compile, no creation of static library
• consuming libraries do not list a (useless?) static library in their linker options

I'd love feedback on my suggestion or reasons why the sample for header-only-library produces a static library.

[lacasseio]

You are right the implementation of that sample is a workaround. Removing the artifact from the outgoing artifact could be a better workaround. Usually, we avoid removing elements once added to a collection in Gradle as some action may have already been triggered which could have created more objects and expect the elements to be present. However, I think in this case you could remove it. You could try a PR in the native-samples repository.

[lacasseio]

Alternatively, we can look into adding a header-only-library to the Nokee plugins. Feel free to open an issue over there and we can talk about your use case, expected UX from the DSL's perspective and compatibility with other plugins.

[Brenne]

thank you @lacasseio for this really quick feedback! I opened a PR in the native-samples repository. I think for the header-only-library plugin the scope is relatively small. Thanks for pointing me to Nokee plugins, there are other tasks (publishing/exporting of compiler / linker args) that require a more complex plugin for this I'll consider opening an issue there.

[lacasseio]

There are several use cases that I saw with header-only library. Some of which are packing multiple headers into a single header (sort-of like compiling the headers together), distribution/publishing, testing. Some header libraries are mostly header except for some features where a precompiled library can be used. It could mirror the feature/capability from the Java plugin. As long as the sample provides the features you need, then it should be alright.