I want to overhaul the MSVC build system somewhat and want to discuss my plans.
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 reasons are:
. 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 suspect.
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.
Thoughts? cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match