This repository was archived by the owner on May 3, 2024. It is now read-only.
update dictionary generation procedure #73
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tomeichlersmith
force-pushed
the
update-dict-gen
branch
from
25ea7f7 to
69b01e3
Compare
instead of writing the dictionary file and then compiling it with the library, we can use a slightly newer method where we attach the dictionary to the already prepared target. This lets us use CMake's ability to change the include paths depending on which interface they are being accessed from (BUILD or INSTALL) and have the generated dictionary files updated accordingly this change does have downstream effects; however, namely 1. Need to update the cmake module to wrap the include paths in the BUILD_INTERFACE generator 2. Need to prune any use of the EventDef.h header which is now removed
tomeichlersmith
force-pushed
the
update-dict-gen
branch
from
69b01e3 to
4c3ce7f
Compare
Member
Author
|
Working in framework-testbench... The current code is working well when issuing successive After a clean buildWe see that successive Issue: Calling
|
Member
Author
|
This cmake stuff still works in the production scenario. I tested this within the testbench: To un-do source deletion |
Member
Author
|
I can mock-up some CMake stuff to only generate the LinkDef when its inputs change, but - for some reason I cannot understand - the dictionary fails to link properly when re-compiling without re-writing the LinkDef. I'm leaving this here for future in case someone thinks of someway around this. For now, I think re-linking is a quick enough procedure that we can ignore that burden and just re-write the LinkDef if CMake Code to re-write LinkDef if Inputs Changemacro(write_linkdef)
# the following writes the LinkDef file using the CMake global variables
# namespaces and dict that are lists appended to by the register_event_object function
message(STATUS "Building ROOT dictionary LinkDef")
set(linkdef_filepath ${PROJECT_BINARY_DIR}/include/Framework/EventDictLinkDef.h)
file(WRITE ${linkdef_filepath} "
#ifdef __CINT__
#pragma link off all globals;
#pragma link off all classes;
#pragma link off all functions;
#pragma link C++ nestedclass;
#pragma link C++ nestedtypedef;
")
list(REMOVE_DUPLICATES namespaces)
foreach(namespace ${namespaces})
file(APPEND ${linkdef_filepath} "#pragma link C++ namespace ${namespace};\n")
endforeach()
foreach(entry ${dict})
file(APPEND ${linkdef_filepath} "#pragma link C++ class ${entry}+;\n")
endforeach()
file(APPEND ${linkdef_filepath} "\n#endif\n")
endmacro()
set(linkdef_inputs "namespaces=${namespaces}\ndict=${dict}")
set(linkdef_inputs_filepath ${PROJECT_BINARY_DIR}/LinkDef.inputs)
if (NOT EXISTS ${linkdef_inputs_filepath})
file(WRITE ${linkdef_inputs_filepath} "${linkdef_inputs}")
write_linkdef()
else()
file(READ ${linkdef_inputs_filepath} linkdef_current_inputs)
if ("${linkdef_current_inputs}" STREQUAL "${linkdef_inputs}")
# re-cmake without modification to linkdef
else()
# re-cmake with modification to linkdef
file(WRITE ${linkdef_inputs_filepath} "${linkdef_inputs}")
write_linkdef()
endif()
endif() |
This was referenced Oct 9, 2023
Contributor
|
This looks really good. One question, does the placement of the headers in the build directory mean that an install will depend on the contents of the build directory? For a normal C++ setup it shouldn't but ROOT isn't always a normal C++ setup |
Member
Author
|
Short Answer: No Long Answer: The LinkDef header is only used during the build and compilation of the dictionary. Once the |
Contributor
|
Super! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Instead of writing the dictionary file and then compiling it with the library, we can use a slightly newer method where we attach the dictionary to the already prepared target. This lets us use CMake's ability to change the include paths depending on which interface they are being accessed from (BUILD or INSTALL) and have the generated dictionary files updated accordingly.
In addition to being slightly newer, it allows us to avoid writing files into the source tree. This means users will be able to just
rm -r buildinstead of having to remember to delete the generated headers inFramework/include/Frameworkif a new event object is added.This change does have downstream effects; however, namely
The patches to resolve these effects are copied below for reference.
Still To Do
cmake
Besides the necessary change below, we can also completely remove the
build_event_busandbuild_dictmacros since they are not used anymore.The rest are just the busy-work of pruning the leftover references to the EventDef header.
Ecal
Hcal
SimCore