Quantcast
Channel: Planet PostgreSQL
Viewing all articles
Browse latest Browse all 9642

Andrew Dunstan: A tale of three perls

$
0
0
Sometimes doing things on Windows can be challenging. I have a Windows XP-Pro virtual machine that runs three buildfarm animals, one each for Visual Studio 2008, MIngw and Cygwin. The buildfarm script is written in perl. The buildfarm animal for Visual Studio 2008 is run using ActiveState Perl, and is built against ActiveState Perl also. The Cygwin member is run using Cygwin Perl, and doesn't build against any perl, because that's a bit broken right now - it's on my long list of things to look into. The Mingw member is a bit more complicated. It's build against ActiveState Perl, but part of it has to run using MinGW's DTK perl (so it gets virtual file paths right), and part of it needs to run using ActiveState Perl (so it can use LWP to load results to the web server). That's why the buildfarm script is split into two. All this has worked like this for years.

Recently I added a feature that allows the buildfarm to grab a global lock, so it forces serialization of builds. So now all these need to work together nicely. But they don't, sadly. The Mingw DTK perl and ActiveState Perl use the same mechanism for flock, but Cygwin Perl seems to do its own thing and blithely walks past an flock call that should fail when one of the others has the global lock. Luckily, the global lock is grabbed in a third script, so I was able to get around this problem by having the Cygwin member run ActiveState Perl for the script that grabs the lock, and then have that invoke Cygwin perl to run the rest.

Of course, working all this stuff out occasionally makes my head explode :-)

Viewing all articles
Browse latest Browse all 9642

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>