"Nystrom, William D" <[email protected]> writes: > From the perspective of PETSc users, what does this mean?
You won't have CMake crash on you with exit code 256 because it won't be used. The "cmakegen" step does not need to happen. Builds might be ever so slightly faster. > I have a limited understanding of the PETSc build system right now but > am aware that there is the python component, a cmake component and a > legacy component. There may be other aspects I am not aware of. Will > there still be the python component? Yes, Python is used for configure and it is used to decide which files need to be part of the library. > Is the gmake system replacing cmake? I expect to maintain the (generated) CMake build indefinitely so that people that like IDEs can use it to generate project files. If it turns out that nobody uses that feature, we could remove it. > Will parallel builds be more robust? It should parallelize a bit better than CMake (which has some artificially strict rules). > Will the current "all-legacy" target go away or will it be replaced by > whatever gmake is replacing? It'll probably stick around for a little while so we can fall back to it. I hope to remove it once all the bugs are worked out. Removing the legacy build will let us simplify the library significantly and make it much less error-prone to move source files around. The documentation system still needs the legacy build at the moment, so that will have to be updated before we can remove it.
pgpNLrR3nH28m.pgp
Description: PGP signature
