[CMake] Regeneration of some .cpp files are broken
#1030
Comments
8 tasks
delcypher
pushed a commit
to delcypher/z3
that referenced
this issue
Jun 21, 2017
Previously CMake was not aware of which headers files the generation of `install_tactic.cpp` depended on. Consequently this could result in broken incremental builds if * Existing headers that declared tactics/probes changed. * New tactics/probes were added to new header files. Now the `z3_add_component()` CMake function has been modifed to take an optional `TACTIC_HEADERS` argument which allows the headers that declare tactics/probes to be explicitly listed. The necessary component declarations have been modified to declare their tactic/probe header files. With this information CMake will now regenerate `install_tactic.cpp` correctly. This required the `mk_install_tactic_cpp_internal()` function to be changed to take a list of header files rather than a list of component source directories. The two consumers (CMake and Python/Makefile build systems) of this function have been modified to work with this change. This partially fixes Z3Prover#1030.
delcypher
pushed a commit
to delcypher/z3
that referenced
this issue
Jun 21, 2017
Previously CMake was not aware of which headers files the generation of `install_tactic.cpp` depended on. Consequently this could result in broken incremental builds if * Existing headers that declared tactics/probes changed. * New tactics/probes were added to new header files. Now the `z3_add_component()` CMake function has been modifed to take an optional `TACTIC_HEADERS` argument which allows the headers that declare tactics/probes to be explicitly listed. The necessary component declarations have been modified to declare their tactic/probe header files. With this information CMake will now regenerate `install_tactic.cpp` correctly. This required the `mk_install_tactic_cpp_internal()` function to be changed to take a list of header files rather than a list of component source directories. The two consumers (CMake and Python/Makefile build systems) of this function have been modified to work with this change. This partially fixes Z3Prover#1030.
delcypher
pushed a commit
to delcypher/z3
that referenced
this issue
Jun 21, 2017
Previously CMake was not aware of which headers files the generation of `gparams_register_modules.cpp` depended on. Consequently this could result in broken incremental builds if * Existing headers that declared module description/parameters change. * New headers are added that declare module description/parameters. * `.pyg` files that generate header files that declare module description/parameters change Now the `z3_add_component()` CMake function has been modifed so that * All header files that are generated from `.pyg` files are added as dependencies and are scanned from module description/parameter declarations. This implicit dependency of `gparams_register_modules.cpp` depending on other generated header files seems unnecessary complex. We should revisit this design decision once the Python/Makefile build system is deprecated. * The function now takes an optional `EXTRA_REGISTER_MODULE_HEADERS` argument which allows the headers that declare module description/paramters to be explicitly listed. With this information CMake will now regenerate `gparams_register_modules.cpp` correctly. This required the `mk_gparams_register_modules_internal()` function to be changed to take a list of header files rather than a list of component source directories. The two consumers (CMake and Python/Makefile build systems) of this function have been modified to work with this change. This partially fixes Z3Prover#1030.
delcypher
pushed a commit
to delcypher/z3
that referenced
this issue
Jun 21, 2017
Previously CMake was not aware of which headers files the generation of `gparams_register_modules.cpp` depended on. Consequently this could result in broken incremental builds if * Existing headers that declared module description/parameters change. * New headers are added that declare module description/parameters. * `.pyg` files that generate header files that declare module description/parameters change Now the `z3_add_component()` CMake function has been modifed so that * All header files that are generated from `.pyg` files are added as dependencies and are scanned from module description/parameter declarations. This implicit dependency of `gparams_register_modules.cpp` depending on other generated header files seems unnecessary complex. We should revisit this design decision once the Python/Makefile build system is deprecated. * The function now takes an optional `EXTRA_REGISTER_MODULE_HEADERS` argument which allows the headers that declare module description/paramters to be explicitly listed. With this information CMake will now regenerate `gparams_register_modules.cpp` correctly. This required the `mk_gparams_register_modules_internal()` function to be changed to take a list of header files rather than a list of component source directories. The two consumers (CMake and Python/Makefile build systems) of this function have been modified to work with this change. This partially fixes Z3Prover#1030.
delcypher
pushed a commit
to delcypher/z3
that referenced
this issue
Jun 21, 2017
Previously CMake was not aware of which headers files the generation of `mem_initializer.cpp` depended on. Consequently this could result in broken incremental builds if * Existing headers that declare memory initializers/finalizers change. * New headers are added that declare memory initializers/finalizer. Now the `z3_add_component()` CMake function has been modifed so that it now takes an optional `MEMORY_INIT_FINALIZER_HEADERS` argument which allows the headers that declare memory initializers/finalizers to be explicitly listed. With this information CMake will now regenerate `mem_initializer.cpp` correctly. This required the `mk_mem_initializer_cpp_internal()` function to be changed to take a list of header files rather than a list of component source directories. The two consumers (CMake and Python/Makefile build systems) of this function have been modified to work with this change. This partially fixes Z3Prover#1030.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the CMake build system fails to re-generate the
install_tactic.cpp,mem_initializer.cpp, andgparams_register_modules.cppfiles when the headers that are used to generate these files change.The reason for this is because CMake is currently unaware that the generation of these files depends on certain header files.
We cannot use shell globing in CMake to fix this because this will fail in the case that new header files are added. The right way to fix this is to change the interface of
z3_add_component()so that header files that need to be scanned to generate header files are explicitly listed.When I have the time I'll fix this. This blocks #986.
The text was updated successfully, but these errors were encountered: