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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

Reply via email to