Automatically discovering the minimal header install set

Code
1

I have an install component ae_sdk that produces the client-facing SDK. We want the SDK to contains the minimal set of headers required. Currently we achieve this by compiling a sample SDK project with the gcc -H flag (print header dependencies) and manually reduce this output down to the minimal set of SDK headers, then manually update the cmake header set, finally producing something like this:

target_sources (ae_core PUBLIC
                        FILE_SET public_sdk_headers
                          TYPE HEADERS
                          FILES
                            Atomic.hpp
                            Exception.hpp
                            Logger.hpp
                            OS.hpp
                            TimeStamp.hpp
                            Utils.hpp
                            SpinLock.hpp
                            Lock.hpp
                            ConcurrentBuffer.hpp
                            CircleBuffer.hpp)

This is quite cumbersome and needs to be repeated whenever the SDK changes. Has anyone seen a way to automate this process? AFAIK cmake does not offer any features along these lines.

My first thought was to write a cmake module that attempts to automate our manual gcc -H approach. Any insights or experience appreciated.

2

Personally I think that’s backwards. You should make a conscious decision about which of your headers are part of your SDK’s public API. A common strategy is to separate out public from private headers by putting them in separate directories. Then it is absolutely clear which of your headers you’re intending to be public and which need to be updated with care so you don’t break compatibility between releases.

It sounds like you are not controlling which headers you make public. If one of your developers starts using an internal header that was never intended to be made public, your approach of letting the compiler tell you which ones are used and distributing those would not catch that. It also breaks consumers if you suddenly stop using a particular header in your sample for some reason, since it would stop being distributed as part of your SDK.

3

I agree with all those risks you outline, but the automation I’m proposing doesn’t preclude an additional manual inspection of the resulting public SDK header set, which we would most definitely be doing.

For some additional context this is for a very large and longstanding production codebase that has never had an SDK associated with it before. It is initially only a single release to a select client. So some pragmatic automation to give us the “minimum functional” header set prior to manual curation would be very helpful, especially since components are being added frequently at the moment.