Thread: allow running parts of src/tools/msvc/ under not Windows
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. This part does not really depend on anything particular to Windows, so it's possible in principle. There are some minor dependencies on Windows, however, that need to be worked around. I have had some local hacks for that for a while, and I took a moment to clean them up and make them presentable, so here they are. Interested? To test, apply the patch and run perl src/tools/msvc/mkvcbuild.pl . -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
On Thu, Feb 13, 2020 at 12:00:54PM +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. This > part does not really depend on anything particular to Windows, so it's > possible in principle. There are some minor dependencies on Windows, > however, that need to be worked around. I have had some local hacks for that > for a while, and I took a moment to clean them up and make them presentable, > so here they are. Interested? > > To test, apply the patch and run perl src/tools/msvc/mkvcbuild.pl . $ perl src/tools/msvc/mkvcbuild.pl . Warning: no config.pl found, using default. Unable to determine Visual Studio version: The nmake command wasn't found. at /home/ioltas/git/postgres/src/tools/msvc/Mkvcbuild.pm line 92. Is that the expected result? -- Michael
Attachment
On 2020-02-13 13:04, Michael Paquier wrote: > On Thu, Feb 13, 2020 at 12:00:54PM +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. This >> part does not really depend on anything particular to Windows, so it's >> possible in principle. There are some minor dependencies on Windows, >> however, that need to be worked around. I have had some local hacks for that >> for a while, and I took a moment to clean them up and make them presentable, >> so here they are. Interested? >> >> To test, apply the patch and run perl src/tools/msvc/mkvcbuild.pl . > > $ perl src/tools/msvc/mkvcbuild.pl . > Warning: no config.pl found, using default. > Unable to determine Visual Studio version: The nmake command wasn't > found. at /home/ioltas/git/postgres/src/tools/msvc/Mkvcbuild.pm line 92. > Is that the expected result? No, I had apparently created by own fake "nmake" shell script some time ago to work around that. Here is a new patch with that taken care of, too. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
On Thu, Feb 13, 2020 at 02:24:43PM +0100, Peter Eisentraut wrote: > On 2020-02-13 13:04, Michael Paquier wrote: > > On Thu, Feb 13, 2020 at 12:00:54PM +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. This > > > part does not really depend on anything particular to Windows, so it's > > > possible in principle. There are some minor dependencies on Windows, > > > however, that need to be worked around. I have had some local hacks for that > > > for a while, and I took a moment to clean them up and make them presentable, > > > so here they are. Interested? > > > > > > To test, apply the patch and run perl src/tools/msvc/mkvcbuild.pl . > > > > $ perl src/tools/msvc/mkvcbuild.pl . > > Warning: no config.pl found, using default. > > Unable to determine Visual Studio version: The nmake command wasn't > > found. at /home/ioltas/git/postgres/src/tools/msvc/Mkvcbuild.pm line 92. > > Is that the expected result? > > No, I had apparently created by own fake "nmake" shell script some time ago > to work around that. Here is a new patch with that taken care of, too. 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.
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.
I don't have any particular objection to the patch as given, it
just doesn't sound helpful for me.
regards, tom lane
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
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-02-13 16:36, Tom Lane wrote:
>> 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.
I see. No objection then.
regards, tom lane
On Thu, Feb 20, 2020 at 09:31:32AM -0500, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> 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. > > I see. No objection then. None from here either, and the patch is working correctly. -- Michael
Attachment
On 2020-02-21 05:00, Michael Paquier wrote: > On Thu, Feb 20, 2020 at 09:31:32AM -0500, Tom Lane wrote: >> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >>> 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. >> >> I see. No objection then. > > None from here either, and the patch is working correctly. committed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> committed
crake says that this doesn't pass perlcritic.
regards, tom lane
On 2020-02-21 21:25, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> committed > > crake says that this doesn't pass perlcritic. OK, fixed. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services