No, @craig.scott , not what I was expecting but totally an answer I was hoping for. Thanks for such a thorough explanation.
The discrepancy in how PUBLIC/PRIVATE effects compilation was exactly the type of thing I wanted to be sure I WASN’T doing so it’s good to know that I should, at the very least, go back to my original paradigm of public headers and private .cpp’s.
I’ll start looking into file sets and see if that helps with anything. I’d really like the generated Xcode and VS projects to resemble what the developers would have setup themselves so that it’s as invisible as possible.
I’ve found that the following will successfully reorganize all the code from my library target (XYZ) into the original folder structure in the IDE, so that’s really helpful.
# inside the XYZ CMakeLists.txt
get_target_property(TARGET_SOURCES XYZ SOURCES)
source_group(TREE ${CMAKE_SOURCE_DIR} FILES ${TARGET_SOURCES})
The issue I’m still trying to solve, if you have any ideas, is removing files from the IDE that are shown redundantly.
If there was a way to say something like the pseudocode below, it would be nice to hide the library code inside the APP target because it’s already in the library target in the IDE.
#inside the APP CMakeLists.txt
get_target_property(TARGET_SOURCES XYZ SOURCES)
source_group(<HIDE> FILES ${TARGET_SOURCES})
(Hope that makes sense)