Re: msvc and vista fun

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.
> 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.

Output:

E:\prog>perl run_build.pl --test
[17:51:47] checking out source ...
[17:52:17] checking if build run needed ...
[17:52:30] copying source to pgsql.3840 ...
3152 File(s) copied
[17:53:44] running configure ...
[17:53:44] running make ...
[18:27:50] running make check ...
[18:27:50] running make install ...
Branch: HEAD
Stage Install failed with status 2

from the bottom of the make log:

Build FAILED.
.\src\backend\utils\adt\oracle_compat.c(898): warning C4090: 'function'
: different 'const' qualifiers
.\src\backend\utils\adt\oracle_compat.c(900): warning C4090: 'function'
: different 'const' qualifiers
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
2 Warning(s)
12 Error(s)

Relevant perl code executed by buildfarm:

chdir "$pgsql/src/tools/msvc";
@makeout = `build 2>&1`;
chdir $branch_root;
my $status = $? >>8;

Could it possibly be that the exit status has only low bits set, and
isn't what should be returned by wait()? I am checking on this now ....
(time passes) ... no, the raw status returned is in fact 0.

Now, I see that we do something different in the install case, which is
why the error gets trapped there. For install, we don't call the .bat
file at all, we call the install script directly:

chdir "$pgsql/src/tools/msvc";
@makeout = `perl install.pl "$installdir" 2>&1`;
chdir $branch_root;
my $status = $? >>8;

So it looks like the .bat files are not collecting the exit status and
passing it on correctly.

>
>
>> state to the buildfarm script, and finally got a failure at the install
>> stage. That means that we simply can't rely on this build system to give
>> us accurate state on the buildfarm - we might have had a code breakage
>> but it won't always tell us that.
>>
>
> At least it broke eventually :-) But I agree that's a big problem.
>

yes.

>
>
>> 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

>
>> 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 ?

> 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"?

>
> 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.

cheers

andrew