Re: MSVC build system

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MSVC build system
Date: 2008-03-12 19:28:23
Message-ID: 200803121928.m2CJSNb27240@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Added to TODO for Win32:

o Convert MSVC build system to remove most batch files


http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php

---------------------------------------------------------------------------

Andrew Dunstan wrote:
>
> 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

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2008-03-12 19:28:59 Re: BUG #4027: backslash escaping not disabled in plpgsql
Previous Message Dave Page 2008-03-12 19:20:01 Re: [HACKERS] Move the developers wiki?