I want to overhaul the MSVC build system somewhat and want to discuss my
The first thing I want to do is get rid of at least most of the .bat
files in it altogether and make a single coherent perl-based system. The
. the XP_EXIT_FIX hack we built in to cater for the XP command processor
doesn't actually work on XP - if it's turned on it fails too often (e.g.
on build warnings) and if it's turned off if doesn't fail often enough
(e.g. on build errors).
. it's unnecessarily complex. For example, the vcregress.bat file calls
a perl script to create a temporary .bat file which it then calls.
. we need perl anyway, so why not write it all in perl? I venture to
suggest that the majority of our developers are more at home in perl
than in the arcane syntax of the Windows command processor, so we might
be less reliant on a tiny group of people (Magnus and Dave, basically)
to maintain the build system.Writing it all in perl would give us a
chance to make the whole system more coherent and data driven.
. the .bat files have serious (from my POV) limitations / errors anyway.
e.g. vcregress.bat has a hardcoded temp port (a definite nono for a
machine running buildfarm and a departure from the regression make file)
and also does not at all honor the MAX_CONNECTIONS environment setting.
It also hardcodes the use of the parallel schedule for installcheck,
unlike the same named test on Unix.
In the longer run I want to make the whole system more data driven, so
that it's comparatively easy for someone to add stuff.
The whole thing needs proper documentation for developers too. Right
now, discovering where to add a new installation file, for example,
requires you to dig into the code which can be rather bewildering, I
Anyway, the first part of what I want to achieve is to replace the
build.bat and vcregress.bat files with perl equivalents, with the
errors/omissions fixed. Along the way, getregress.pl would become
redundant. Apart from fixing the issue with using the systems "dir"
command rather than using File::Find, which I will revisit, I think
that's all I would do now, given how close we are to Beta. The rest can
wait until after we release.
I should add that some at least of this is my fault - Magnus showed me
at least parts of the system and asked my advice, and I didn't pay close
enough attention. It was only when (much later) I started to try to use
it seriously that I understood how much work was still needed.
pgsql-hackers by date
|Next:||From: Joshua D. Drake||Date: 2007-08-27 15:08:34|
|Subject: Problem with recent permission changes commits|
|Previous:||From: Albe Laurenz||Date: 2007-08-27 14:46:53|
|Subject: Re: LDAP service lookup|