Re: WIP: About CMake v2
От | Noah Misch |
---|---|
Тема | Re: WIP: About CMake v2 |
Дата | |
Msg-id | 20150901143239.GC2904258@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: WIP: About CMake v2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP: About CMake v2
|
Список | pgsql-hackers |
On Tue, Sep 01, 2015 at 12:49:55AM -0400, Tom Lane wrote: > Noah Misch <noah@leadboat.com> writes: > > On Fri, Aug 28, 2015 at 01:28:49PM -0300, Alvaro Herrera wrote: > >> If it allows us to get rid of our custom MSVC scripts, it's a huge > >> benefit, for sure -- that has been a huge pain in the neck since day > >> one. > > > Moreover, I suggest beginning with a patch that replaces the src/tools/msvc > > build system with CMake. One can test almost all Windows configurations using > > two machines, so author and reviewer can test most everything. src/tools/msvc > > has more defects than the GNU make build system, so the minimum-quality > > acceptable replacement is easier to deliver. With CMake driving all MSVC > > builds, it would be much easier to gradually extend to other platforms. > > mmm ... dunno about that plan. In the first place, you seem to be > recommending that YUriy incorporate all the deficiencies of src/tools/msvc > into his first draft and then hope somehow to fix them later. No, src/tools/msvc is a poor source of implementation ideas. Implement the CMake build in idiomatic CMake style. Write an initial patch sufficient so we could delete src/tools/msvc in the same patch, and make little or no attempt to cover other cases. That's my suggestion. > In the > second place, I think that the core problem here involves being sure > we can still cover all the portability issues that have been laboriously > hacked into the autoconf/gmake build system over nigh two decades. I agree that the first patch should demonstrate the CMake programming environment's sufficiency for open-ended portability adaptations. I doubt demonstrating that requires actual porting to more than a platform or two. > Starting from a build system that was designed to cover exactly one target > platform, and has never been asked to do anything more than that, doesn't > sound like a recipe for success there. Fair point. Perhaps replace src/tools/msvc completely and build+install on at least one reasonable GNU/Linux configuration? A monolithic patch replacing the GNU make build system with a CMake build system sounds far too hard to write and review; we should expect to maintain those two build systems in parallel for awhile. Reconciling the MSVC and GNU make build systems is a chronic problem today, so it would be a big plus to have no more than two of MSVC, GNU Make and CMake build systems to maintain.
В списке pgsql-hackers по дате отправления: