Including headers for all libraries based on ROOT_STANDARD_LIBRARY_PACKAGE

[bernhardmgruber]

Partially solves: ROOT-10915

Reasoning from the ticket:

It seems most header files are not added to the library targets that compose ROOT. This is most imminent to me when I create a Visual Studio project by CMake. Almost all header files are missing in the solution explorer.

While this still allows to build ROOT, the IDE experience is severly limited. Automatic code refactoring and static analysis fails to a large degree, because the headers are not considered part of the project. E.g. the clang-tidy integration in Visual Studio cannot fix any header files.

[amadio]

Have a look at ROOT_GENERATE_DICTIONARY for the logic to check if the header exists, it may make sense to something similar here or split that search logic into its own macro or function. ARG_HEADERS may actually contain more than just the headers for a given target, so I'm not sure we can use it verbatim to add headers to the targets. It should be ok if all targets use NODEPHEADERS properly, but it's probably worth checking anyway.

[bernhardmgruber]

I had a look and the logic seems overly complex to me. I would like to keep it simple. I improved the message in case the header is not found and on the current master, it is never triggered. Therefore this logic seems to suffice.

[vgvassilev]

Shouldn't we explicitly enumerate all sources when calling ROOT_STANDARD_LIBRARY_PACKAGE nowadays?

[bernhardmgruber]

YES! But people seem to have a different understanding of what a source is. In ROOT it seems people just add sources that need to be compiled. IMO at least all files containing code should be added.

For ROOT, that's a rather big change. I can try to do that for the libraries I will be working with, but I would like to have more support to move in this direction. Maybe we should discuss this in a team meeting.

[bernhardmgruber]

So in the meantime I can work pretty comfortably with the Open Folder mode in Visual Studio or with CLion. So this might still be an issue for some IDE users, but I do not need it solved.

Should we close the PR?

[guitargeek]

IDE experience is severly limited [...] E.g. the clang-tidy integration in Visual Studio cannot fix any header files.
Should we close the PR?

I wonder if this also applies to other clang-tidy setups? For example, I never got any warning from run-clang-tidy about a header file from the ROOT repository. That's suspicious.

I'd suggest we check if static analysis tools like clang-tidy actually hover our header files at this point, and if they do, the PR can be closed.

Assigning this PR to me because I'll probably do this check at some point, but probably not any time soon. So whoever is reading this and wants to do some work on code analysis, please feel free to re-assign!

[github-actions]

Test Results

    18 files      18 suites   4d 2h 59m 10s ⏱️
 2 687 tests  2 687 ✅ 0 💤 0 ❌
46 529 runs  46 529 ✅ 0 💤 0 ❌

Results for commit 91d8e5f.

[ferdymercury]

Another related issue is that sometimes the IDE get's confused and it opens the header copied to the build-dir rather than the original header, since it's not part of the CMake target. So you start modifying the wrong one, then rebuild, and it get's overwritten and you lose your changes.

[ferdymercury]

Recent CMake also allows to distinguish between PRIVATE (such as those of RooFit or in core/base/src/TListOfDataTypes.h) and PUBLIC headers. See https://discourse.cmake.org/t/file-set-xyz-is-listed-in-interface-file-sets-of-w-but-has-not-been-exported/9131/4

Sth like:

set(FULL_BASE_HEADERS ${BASE_HEADERS})
list(TRANSFORM FULL_BASE_HEADERS PREPEND ${CMAKE_CURRENT_SOURCE_DIR}/inc)
if(NOT CMAKE_VERSION VERSION_LESS "3.23.0") # https://discourse.cmake.org/t/file-set-xyz-is-listed-in-interface-file-sets-of-w-but-has-not-been-exported/9131/3
  target_sources(
Core
      PRIVATE
      FILE_SET private_header_files
      TYPE HEADERS
      BASE_DIRS ${BASE_HEADER_DIRS}
      FILES
          ${FULL_BASE_HEADERS}
    PUBLIC etc etc

see details #18419

Might also help with #8709 by @hageboeck, #16327 by @vgvassilev and with cpack https://its.cern.ch/jira/browse/ROOT-6428