On Wed, Apr 27, 2016 at 08:15:05AM +0000, Christian Ullrich wrote: > * From: Michael Paquier [mailto:michael.paqu...@gmail.com] > > > On Wed, Apr 27, 2016 at 4:06 PM, Christian Ullrich <ch...@chrullrich.net> > > wrote: > > > > * From: Michael Paquier [mailto:michael.paqu...@gmail.com] > > > >> vcbuild also supports /m. Wouldn't it make sense to have a environment > > >> variable flag for it as well? vcbuild has been replaced by msbuild in > > >> VS2010 but I would think that in back-branches this would have value > > >> for users still compiling with VS2008 or older, and those are still > > >> supported things. > > > > > > Good point, but I have no installation of 2008 around, so I cannot test > > > it. Perhaps there is someone around who could do that (just add the > > > $msbflags as the first argument to vcbuild)? > > > > I forgot that I have actually one! Bumping my Win7 VM CPU from 1 to 2, > > and using VS2008 command prompt with vcbuild /m I am not seeing > > issues. Moving symbols.out would be the main issue, but I am not > > noticing problems related to that. > > OK then, hopefully last round attached.
Every vcbuild and msbuild invocation ought to recognize this variable, so please update the two places involving ecpg_regression.proj. Apart from that, the patch looks good. I was tempted to back-patch this. The risk to back branch users seems negligible, and it would be convenient for me as a person who builds all branches. That reason is not good enough, so I plan not to back-patch. I feel like I might be missing a stronger reason to back-patch. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers