postgres_cmake
postgres_cmake copied to clipboard
stalkerg
Contrib modules built by default
We have discussed this in our company and nobody knows why need build contribs separated. In Postgres many strange practices if we can do better we must do better.
I wish to discuss this approach in hackers.
Yeah, I think discussion on hackers is the way to go. My view is that to make it easy for this build tool change to be merged it would be wise to make it behave as similarly as possible to the current build system. After it is in, then sensible changes to default targets etc can be considered :-)
Ooops we have really trouble here and I forgot about it. You can't add to INSTALL optional target. https://cmake.org/cmake/help/v3.7/prop_tgt/EXCLUDE_FROM_ALL.html#prop_tgt:EXCLUDE_FROM_ALL
We have here big difference between CMake and GNUMake concepts. Have you any idea? I thinking about "cmake modules" but it is not exactly what we need.
I'd suggest setting up a target so that after cmake step is done, then 'make contrib' builds the contrib modules. But float this idea on hackers...get their buy-in and then it will be easier!
But float this idea on hackers...get their buy-in and then it will be easier!
I agree but we have technical reasons.
I'd suggest setting up a target so that after cmake step is done, then 'make contrib' builds the contrib modules.
You can exclude "contrib" target from "all" target but you also exclude from INSTALL target.
Installing a target with EXCLUDE_FROM_ALL set to true has undefined behavior.
Ah yes, so won't work as I have suggested. So it might be ok if you have to 1/ specify you want contrib at cmake time if 2/ you want to build (and install) it at make time. This is the type of thing to discuss on hackers :-)
So it might be ok if you have to 1/ specify you want contrib at cmake time if 2/ you want to build (and install) it at make time.
In GNUMake you have many enter points and it help here.
This is the type of thing to discuss on hackers :-)
I think too but at first I able be make README.cmake and make new patch.
New patch - great idea. Now it might be wise to look at adding a section into doc/src/sgml/installation.sgml about building with cmake (essentially similar to what you have in README.cmake). The reviewers will insist that the generated docs cover the new way to build postgres. If SGML is completely alien to you I can probably transcribe whever you have in README.cmake into a new section :-)