Greg Ercolano wrote: > I find that to get FLTK to build successfully in the Microsoft IDE, > I have to set the parallel builds to '1', eg: > > Go into Tools -> Options -> Project Solutions -> Build and Run > ..and set "maximum number of parallel project builds" to 1. [..] > I'm guessing there might be something wrong with our dependencies that > is causing parallel builds not to work right, e.g. the apps try to build > before the lib has been completely built. Or maybe it's a buggy IDE..
I've confirmed switching the above "parallel builds" value from 1 <-> 2 affects build success with VS 2008; 1 works, 2 fails. Looking closely at the failures, the earliest are: 18>Deleting intermediate and output files for project 'resizebox', configuration 'Release|Win32' 18>resizebox : error PRJ0008 : Could not delete file '\\meade\net\tmp\fltk-1.3.x-svn\ide\VisualC6\Release\vc90.idb'. 18>Make sure that the file is not open by another process and is not write-protected. It's complaining about multiple vc90.idb files being open at the same time (file in use by another process). The cause seems to be, when building in 'Release' mode, the intermediate files (vc90.idb) are written to the same pathname, eg. Release\vc90.idb. Not a problem when building in parallel (they get re-created for each project), but during a parallel build, if two or more projects build in parallel, they /all/ create Release\vc90.idb, and all but the first fail because the file's already in use. A smarter compiler would know to write its friggin 'intermediate files' with unique names, and not to just use "vc90.idb" for everything >%^( I sniffed around on the web; apparently there's something called the "Intermediate Directory" settings that control where these files go. These settings seem to be in our .dsp files, and are "correct" for "Debug" builds, but "wrong" for "Release" builds. [e...@tahoe] $ grep "Intermediate" keyboard.dsp # PROP BASE Intermediate_Dir "Release" <-- BAD: non-unique name "Release"! # PROP Intermediate_Dir "Release" # PROP BASE Intermediate_Dir "keyboard_" <-- GOOD: /unique/ name <projectname><underbar> # PROP Intermediate_Dir "keyboard_" I found if I change all instances of "Intermediate_Dir" entries to read: # PROP BASE Intermediate_Dir "$(ProjectName)_" # PROP Intermediate_Dir "$(ProjectName)_" # PROP BASE Intermediate_Dir "$(ProjectName)_" # PROP Intermediate_Dir "$(ProjectName)_" ..where $(ProjectName) is literal -- the VS compiler apparently expands this variable at run time in place of the project's own name. This solves the problem of the vc90.idb errors being 'in use' during parallel builds, so now I can get it all to build in parallel with no errors. Wrote a small perl script to the above modifications automatically: --- snip #!/usr/bin/perl -w use strict; # # Fix FLTK's ide/VisualC/*.dsp files for parallel builds # erco 1.00 04/30/2010 # my $outdir = "./new-dsp"; if ( ! -d $outdir ) { unless(mkdir($outdir)) { die "mkdir($outdir): $!\n"; } } foreach my $dsp ( glob("*.dsp") ) { print STDERR "-- Reading $dsp, Writing $outdir/$dsp\n"; unless (open(DSP, "<$dsp")) { die "$dsp: $!\n"; } unless (open(OUT, ">$outdir/$dsp")) { die "$outdir/$dsp: $!\n"; } while (<DSP>) { s/[\r\n]*//g; if ( $_ =~ /Intermediate_Dir/ ) { printf(STDERR "%20s: %-50s ", $dsp, $_); # DIAGNOSTICS: BEFORE $_ =~ s%Intermediate_Dir.*%Intermediate_Dir "\$(ProjectName)_"%; printf(STDERR "%-50s\n", $_); # DIAGNOSTICS: AFTER } print OUT $_ . "\r\n"; # MS CRLF FORMAT } close(OUT); close(DSP); } --- snip Just run it while in the ide/VisualC6 dir; it converts "*.dsp" in the cwd and writes new .dsp files to the subdir "./new-dsp/". So after you run the script, you would: mkdir old-dsp move *.dsp old-dsp move new-dsp\*.dsp . del *.vcproj ..then load the fltk.dsw in VS, and test. If the above all makes sense, I can check the modified *.dsp files into SVN with those fixes. Should solve those damn vc90.idb "file in use" errors once and for all.. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev