Make directory-level enabling recursive#122
Make directory-level enabling recursive#122FeignClaims wants to merge 4 commits intomodern-cmake:mainfrom
Conversation
|
Thanks for your contribution! I will look at it and review this weekend. |
|
Hi @alexreinking, just wanted to bring attention to this PR. Would you mind taking a look when you have a chance? Thanks! |
|
We're going to need to think about how to make this work with CXX_MODULE and HEADER_SET file sets that specify a BASE_DIR. For sources in those properties, we need to
Basically, if someone has a base dir of |
I see, but I'm afraid I won't have time to modify this PR in the coming month. Let's change this PR to a draft PR for now, and I'll set it to "Ready for review" once I've made the necessary changes. |
|
Oh boy and while we're working on total correctness, we need to make sure that translating generated cpp2 sources works correctly |
Currently when enabling a directory by setting
CPPFRONT_NO_MAGICtofalse, only targets right inCMAKE_CURRENT_SOURCE_DIRwill get automatic cpp2-to-cpp translation.This conflict with the behavior that
find_packagemakes the package available for all subdirectories inside the directory. That is, if users already callfind_packageinsrc, they are not required tofind_packageagain insrc/app.The pr fix the above conflict by
cppfront_enable_directories) recursive.${CMAKE_SOURCE_DIR}/app/src/main.cpp2to${CMAKE_BINARY_DIR}/_cppfront/app/src/main.cpp.The second change enables users to navigate the corresponding cpp files. I've tested that the cpp2 file
target_source-ed by multiple targets won't translate more than once, so I think this change is ok compared to the hash-and-rename.A better solution might be making the cpp2-to-cpp translation registration behave like handling
uicautomatically for cmake-qt, but I failed to learn how that works.