Re: allow running parts of src/tools/msvc/ under not Windows
От | Peter Eisentraut |
---|---|
Тема | Re: allow running parts of src/tools/msvc/ under not Windows |
Дата | |
Msg-id | 2cb24450-34cc-23c9-3464-958b152ac294@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: allow running parts of src/tools/msvc/ under not Windows (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: allow running parts of src/tools/msvc/ under not Windows
|
Список | pgsql-hackers |
On 2020-02-13 16:36, Tom Lane wrote: > Julien Rouhaud <rjuju123@gmail.com> writes: >> On Thu, Feb 13, 2020 at 02:24:43PM +0100, Peter Eisentraut wrote: >>>> When making build system changes that risk breaking the MSVC build system, >>>> it's useful to be able to run the part of the MSVC build tools that read the >>>> makefiles and produce the project files under a not-Windows platform. > >> With v2 I'm able to successfully run mkvcbuild.pl on linux and macos. I don't >> have any knowledge on compiling with windows, so I can't really judge what it's >> been doing. > > Yeah, I'm wondering exactly how this helps. IME the typical sort of > breakage is "the MSVC build doesn't know that file X needs to be > included when building Y". It seems like just building the project > files will teach one nothing about that type of omission. The main benefit is that if you make "blind" edits in the Perl files, you can verify them easily, first by seeing that the Perl code runs, second, depending on the circumstances, by diffing the created project files. Another is that if you do some nontrivial surgery in makefiles, you can check whether the Perl code can still process them. So the benefit is mainly that you can iterate faster when working on build system related things. You still need to do a full test on Windows at the conclusion, but then hopefully with a better chance of success. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: