Make directory-level enabling recursive #122
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently when enabling a directory by setting
CPPFRONT_NO_MAGIC
tofalse
, only targets right inCMAKE_CURRENT_SOURCE_DIR
will get automatic cpp2-to-cpp translation.This conflict with the behavior that
find_package
makes the package available for all subdirectories inside the directory. That is, if users already callfind_package
insrc
, they are not required tofind_package
again insrc/app
.The pr fix the above conflict by
cppfront_enable_directories
) recursive.${CMAKE_SOURCE_DIR}/app/src/main.cpp2
to${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
uic
automatically for cmake-qt, but I failed to learn how that works.