On Tue, Apr 26, 2016 at 10:09 PM, Christian Ullrich
<ch...@chrullrich.net> wrote:
> The first patch passes the value of the MSBFLAGS environment variable to
> msbuild's command line.
>
> The output of parallel and sequential builds has identical file count and
> size after installing; all tests pass.
If a committer is willing to pick up that, I'd say go for it.
Personally, I have modified some of my windows build scripts in this
area to pass additional flags. Not sure that there are many people in
a similar case than me around though :)
> Even without /m, MSBuild will already run enough compilers to keep all CPUs
> busy whenever it can do that with only a single project's files. With /m, it
> will also process _projects_ in parallel.
>
> One additional fix required is to put gendef.pl's "symbols.out" file into
> the directory it is working on, rather than the source tree root, to avoid
> collisions that cause the parallel build to fail otherwise.
<screen>
-<userinput>build DEBUG</userinput>
+<userinput>build -c DEBUG</userinput>
</screen>
To build just a single project, for example psql, run the commands:
<screen>
<userinput>build psql</userinput>
-<userinput>build DEBUG psql</userinput>
+<userinput>build -c DEBUG psql</userinput>
</screen>
Why is that? Your patch just has a look at argv[0] to see if that's a
debug or release build.
+use File::Spec::Functions qw(splitpath catpath);
This is present since at least perl 5.8, so that's not a blocker.
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.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
