On Sun, Jun 24, 2007 at 08:24:43PM -0400, Andrew Dunstan wrote:
> Magnus Hagander wrote:
> >Andrew Dunstan wrote:
> >  
> >>I am still very unhappy about the way the MSVC builds work. Although we
> >>have managed to make it sort of work with the buildfarm script, it is
> >>distinctly fragile. Last night, for example, I had a build failure due
> >>to a badly installed zlib. The error state didn't come back to the
> >>buildfarm script, which carried on merrily to the check stage, which
> >>also naturally failed, but also didn't manage to give back an error
> >>    
> >
> >I've heard you report this before, and I've tried and failed many times
> >to reproduce it. It has *always* come back with the proper errorlevel
> >when I've tried. So two questions:
> >
> >1) are you absolutely sure that the problem is not in the buildfarm script?
> >  
> Pretty damn sure, yes. This code has functioned correctly on the 
> buildfarm on every other platform since its inception.

I think you are overestimating the cross-platformness of perl...  :-)

> >2) What exactly was the error? So I can try to reproduce that exact
> >problem here and see if I can find out what it is. What did you do
> >wrong, and what was the error messages if you still have the log.
> >  
> I did indeed keep the logs.
> Steps to reproduce: rename your zdll.lib and then run the buildfarm script.


Running this *outside* the buildfarm properly sets errorlevel=1 when it

Running the same test from the buildfarm script on the same machine, and it
picks up the error and reports it just fine.

Since nobody else (AFAIK) has seen this, I'd be inclined to blame something
in your environment. 

Can you run the build in "broken mode" but *without* using the buildfarm
scripts, and see what errorlevel you get? Meaning:
... wait ...
echo %errorlevel%

It should output 1 if that part works, 0 if it fails. That'll tell us if
the problem is in the bf or if it's in the actual build system.

> >>Part of the problem, it seems to me, is that this build system is a
> >>hodge-podge of Perl programs and Windows shell scripts. In at least one
> >>case we call perl to write a dynamically generated .bat file which we
> >>then execute. 
> >>    
> >
> >Which one is that? I can't find it. A simple findstr through all the
> >perl files appears to contain nothing of the sort.
> >  
> perl ../../src/tools/msvc/getregress.pl > regress.tmp.bat
> call regress.tmp.bat
> del regress.tmp.bat

Ah. I was looking at the build parts only, not the regress part. My bad.

Anyway, yes, the vcregress.bat file was the only one on the list that made
sense to consider redoing in perl.

> >>Since the perl is pretty much indispensable (or at least
> >>would need replacing by an engine of similar capability), I think we
> >>should make the whole thing a perl suite with some very minimal .bat
> >>wrappers if necessary.
> >>    
> >
> >That's mostly how it is now, no? What are you referring to specifically?
> >
> >The only longer ones I can see are:
> >
> >builddoc.bat - could certainly be put into perl stuff, but it's not
> >involved in the buildfarm process, so...
> >
> >clean.bat - doesn't really matter, IMO, and again not involved in the
> >buildfarm process
> >
> >vcregress.bat - sure, it could be made perl, but right now you can
> >actually run the regression tests on an installed system without having
> >perl at all... But that's not really a requirement, so we could change
> >that one.
> >  
> perl2exe ?

No way, that's just too ugly :-) Since you basically ship perl packaged
inside the exe anyway, we might as well accept the requirement of perl to
run the regression tests. Actually, ┬┤given the above we *already* require
perl for the regression tests, I had forgotten about that part.

> >The rest are just thin wrappers.
> >  
> Well, my .bat-fu was last in use around DOS6.2, so I'm not mucjh help 
> with them :-)  I don't think they're really thin enough. Why not just 
> have them call "perl scriptname args"?

I guess you could. The point of the split in build.bat today is basically
that you run mkvcbuild separately if you want to work from the GUI. But
that could of course be dealt with with commandline parameters if there's
really a benefit in it. But I'm not sure there is - there's very little
logic in the bat files, and that's what matters IMO.

> >Speaking of wrappers, are you planning to make the buildfarm use the
> >modules instead of the perlscripts? IIRC, I made those modules
> >specifically for the bf - and it should make it even easier to pick up
> >the errors from there.
> >
> >
> Yes, you did. But as I think I told you, I had a rethink about that. The 
> whole point about the buildfarm is to do things as closely to what a 
> human would do as possible, so I don't want to make it use the perl 
> modules like that unless we really really have to. I also want to have 
> as little special casing as possible in the buildfarm.

Ah, you did tell me that. Sorry, forgot about that. Fair 'nuff.


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to