Re: MSVC build system
От | Bruce Momjian |
---|---|
Тема | Re: MSVC build system |
Дата | |
Msg-id | 200803121928.m2CJSNb27240@momjian.us обсуждение исходный текст |
Ответ на | MSVC build system (Andrew Dunstan <andrew@dunslane.net>) |
Список | 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@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: