You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2013/05/07 00:40:57 UTC

Re: Making the Windows Build Easier

On Sat, Apr 13, 2013 at 8:46 PM, Ben Reser <be...@reser.org> wrote:

> The result is the build-svn-deps-win.pl script that I've commited in r1467714.
>
> This script is far from perfect.  It still needs some work on it, but
> it's probably about 90% of the way there to turning setting up a
> Windows development environment into about an hour effort from a
> couple day slog that you have no hope of being able to reproduce.

Giving this a try with 1.8.x RC1

> a) Pick a location to do the build and make a directory to build the
> deps, in my case I put it in C:\Users\breser\svn-trunk-deps.  Download
> the script at http://svn.apache.org/repos/asf/subversion/trunk/tools/dev/build-svn-deps-win.pl
> and put it in this directory.  Open the script in a text editor and
> make sure you install the few dependencies you'll need (Perl, Python,
> 7-Zip and CMake).  Python actually may not be needed for this but it's
> needed for the Subversion build itself.  If presented the option to
> add the commands to your path accept it (Python and Perl will do this
> by default, CMake you have to explicitly decide to do this).  7-zip
> doesn't have one so make a note of where you installed it for later.
> Once you have the dependencies downloaded open the "VS2012 x86 Native
> Tools Command Prompt" (usually found in the Visual Studio Tools
> group).  cd to your directory and run build-svn-deps-win.pl.  If
> 7z.exe is not in "C:\Program Files\7-Zip\7z.exe" you can override this
> by passing "SEVEN_ZIP=C:\Path\To\7z.exe" to the script.  The script
> will then download and build the dependencies for you.  For me on my
> VM setup it takes about 45 minutes for this to run.

I used this option.  Ran into two quick problems that were easy to solve:

1) Script got a 404 when downloading zlib 1.2.7.  I recall seeing
messages about 1.2.8 on the list here so I changed the version in the
script and that solved that problem.

2) Got an error about invalid command line option when it tried to use
7-zip to unpack the tarballs.  Turned out I had an old version
installed.  I installed the latest and that resolved it.

I like that the script can be re-run.

The script then started chugging along and building.  It looks like it
failed at the end of building httpd.  Not really sure why or what is
wrong:

========== Build: 7 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Build: 118 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0
\Common7\IDE\devenv.COM"' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0
\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
Failed building/installing httpd/apr/apu/api (exit code: 512) at build-svn-deps-
win.pl line 245.

Any ideas?  I searched the output for what Failed and do not see
anything referenced.

Searching for all instanced of "Error".  It might be this:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.ta
rgets(347,5): error MSB6003: The specified task executable "CL.exe" could not be
 run. The process cannot access the file 'C:\SVN\deps-1.8.x\build\httpd\modules\
proxy\balancers\Release\cl.write.1.tlog' because it is being used by another pro
cess.


--
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Making the Windows Build Easier

Posted by Ben Reser <be...@reser.org>.
On Tue, May 7, 2013 at 11:50 AM, Mark Phippard <ma...@gmail.com> wrote:
> Yes, started it over from scratch as I was not sure if just re-running
> would be the right thing to do.
>
> In general, what is the process in the future when there are new
> versions of components.  Should I be able to just update the version
> number and re-run the script or should I always start from scratch?

For now probably best to start from scratch.  However, I should be
able to make it able to deal with that.

Re: Making the Windows Build Easier

Posted by Mark Phippard <ma...@gmail.com>.
On Tue, May 7, 2013 at 2:50 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Tue, May 7, 2013 at 2:47 PM, Ben Reser <be...@reser.org> wrote:
>> On Tue, May 7, 2013 at 10:43 AM, Mark Phippard <ma...@gmail.com> wrote:
>>> I am attaching the log file it found.  I also searched the
>>> httxt2dbm.vcxproj file, which seems to be the relevant file, and it
>>> does NOT seem to have that property you set about TrackFiles.  I note
>>> this project file is in the support folder.  Does your script touch
>>> those projects too?
>>
>> I think we're dealing with a race condition that's just not happening
>> on my setup.  I noticed that the modules that failed for me were
>> somewhat random.  So I guess due to differences in systems I'm just
>> not seeing the failures in the support tree.
>>
>> I've added the support tree to the tree of files that I turn off
>> tracking of file accesses in the projects in the latest commit.
>>
>> Can you give that a try?
>>
>> Thanks for your patience in dealing with this.
>
> Yes, started it over from scratch as I was not sure if just re-running
> would be the right thing to do.
>
> In general, what is the process in the future when there are new
> versions of components.  Should I be able to just update the version
> number and re-run the script or should I always start from scratch?

Looks like that latest commit solved it!  Thanks.

Now on to the next steps where I actually build SVN to use the dependencies.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Making the Windows Build Easier

Posted by Mark Phippard <ma...@gmail.com>.
On Tue, May 7, 2013 at 2:47 PM, Ben Reser <be...@reser.org> wrote:
> On Tue, May 7, 2013 at 10:43 AM, Mark Phippard <ma...@gmail.com> wrote:
>> I am attaching the log file it found.  I also searched the
>> httxt2dbm.vcxproj file, which seems to be the relevant file, and it
>> does NOT seem to have that property you set about TrackFiles.  I note
>> this project file is in the support folder.  Does your script touch
>> those projects too?
>
> I think we're dealing with a race condition that's just not happening
> on my setup.  I noticed that the modules that failed for me were
> somewhat random.  So I guess due to differences in systems I'm just
> not seeing the failures in the support tree.
>
> I've added the support tree to the tree of files that I turn off
> tracking of file accesses in the projects in the latest commit.
>
> Can you give that a try?
>
> Thanks for your patience in dealing with this.

Yes, started it over from scratch as I was not sure if just re-running
would be the right thing to do.

In general, what is the process in the future when there are new
versions of components.  Should I be able to just update the version
number and re-run the script or should I always start from scratch?


--
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Making the Windows Build Easier

Posted by Ben Reser <be...@reser.org>.
On Tue, May 7, 2013 at 10:43 AM, Mark Phippard <ma...@gmail.com> wrote:
> I am attaching the log file it found.  I also searched the
> httxt2dbm.vcxproj file, which seems to be the relevant file, and it
> does NOT seem to have that property you set about TrackFiles.  I note
> this project file is in the support folder.  Does your script touch
> those projects too?

I think we're dealing with a race condition that's just not happening
on my setup.  I noticed that the modules that failed for me were
somewhat random.  So I guess due to differences in systems I'm just
not seeing the failures in the support tree.

I've added the support tree to the tree of files that I turn off
tracking of file accesses in the projects in the latest commit.

Can you give that a try?

Thanks for your patience in dealing with this.

Re: Making the Windows Build Easier

Posted by Mark Phippard <ma...@gmail.com>.
On Tue, May 7, 2013 at 12:46 PM, Ben Reser <be...@reser.org> wrote:
> On Tue, May 7, 2013 at 6:14 AM, Mark Phippard <ma...@gmail.com> wrote:
>> On Tue, May 7, 2013 at 2:06 AM, Ben Reser <be...@reser.org> wrote:
>>> Can you look to see that there is a line like this in all the vcxproj
>>> files under modules\proxy\balancers:
>>> <PropertyGroup><TrackFileAccess>false</TrackFileAccess></PropertyGroup>
>>
>> Yes, next to last line right before the closing Project tag.
>
> Now I'm wondering if it isn't recognizing this property setting.  Can
> you check your path to make sure you don't have some other tools on
> the path?  If you run devenv from the terminal you were running this
> in does it start Visual Studio 2012 or some previous version?

I am using the VS 2012 command prompt and it opens VS 2012.

>>> The scripting that adds that bit is not really the greatest.  Perhaps
>>> it's failing for you for some reason.  One possibility here is a
>>> different version of Perl.  I'm using Perl 5.16.3.1603 from:
>>> http://www.activestate.com/activeperl/downloads
>>
>> I am also using ActiveState.  5.12.2 in my case.
>
> Yeah well if the lines are there it shouldn't be an issue.
>
>>> If the above doesn't help, can you try the attached script (adjusting
>>> paths).  I know it's ugly it's basically just a find2perl script that
>>> I threw together to find failed builds while I was using this.  Just
>>> run it while the cd is the trunk and it should point out which bits of
>>> the build have Build FAILED in them.  You can then look at those logs
>>> and you should get a more detailed error.  You very well may only find
>>> what you've already found.
>>
>> There were no attachments.
>
> Oops.  Attached this time.
>
>>> The other comment I have is I did this on Windows 8 x64 (though I only
>>> built 32-bit binaries).  I'm not sure what version of Windows you're
>>> using, but this might be another possible source of issues.
>>
>> Windows 7 x64, doing a 32-bit build.
>
> Okay I'll try it on Windows 7 x64 if I get a chance to later today.

I am attaching the log file it found.  I also searched the
httxt2dbm.vcxproj file, which seems to be the relevant file, and it
does NOT seem to have that property you set about TrackFiles.  I note
this project file is in the support folder.  Does your script touch
those projects too?


--
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Making the Windows Build Easier

Posted by Ben Reser <be...@reser.org>.
On Tue, May 7, 2013 at 6:14 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Tue, May 7, 2013 at 2:06 AM, Ben Reser <be...@reser.org> wrote:
>> Can you look to see that there is a line like this in all the vcxproj
>> files under modules\proxy\balancers:
>> <PropertyGroup><TrackFileAccess>false</TrackFileAccess></PropertyGroup>
>
> Yes, next to last line right before the closing Project tag.

Now I'm wondering if it isn't recognizing this property setting.  Can
you check your path to make sure you don't have some other tools on
the path?  If you run devenv from the terminal you were running this
in does it start Visual Studio 2012 or some previous version?

>> The scripting that adds that bit is not really the greatest.  Perhaps
>> it's failing for you for some reason.  One possibility here is a
>> different version of Perl.  I'm using Perl 5.16.3.1603 from:
>> http://www.activestate.com/activeperl/downloads
>
> I am also using ActiveState.  5.12.2 in my case.

Yeah well if the lines are there it shouldn't be an issue.

>> If the above doesn't help, can you try the attached script (adjusting
>> paths).  I know it's ugly it's basically just a find2perl script that
>> I threw together to find failed builds while I was using this.  Just
>> run it while the cd is the trunk and it should point out which bits of
>> the build have Build FAILED in them.  You can then look at those logs
>> and you should get a more detailed error.  You very well may only find
>> what you've already found.
>
> There were no attachments.

Oops.  Attached this time.

>> The other comment I have is I did this on Windows 8 x64 (though I only
>> built 32-bit binaries).  I'm not sure what version of Windows you're
>> using, but this might be another possible source of issues.
>
> Windows 7 x64, doing a 32-bit build.

Okay I'll try it on Windows 7 x64 if I get a chance to later today.

Re: Making the Windows Build Easier

Posted by Mark Phippard <ma...@gmail.com>.
On Tue, May 7, 2013 at 2:06 AM, Ben Reser <be...@reser.org> wrote:
> On Mon, May 6, 2013 at 4:47 PM, Mark Phippard <ma...@gmail.com> wrote:
>> I have Update 2 installed.
>> http://www.microsoft.com/en-us/download/details.aspx?id=38188
>
> I've installed update 2, still get a completely finished build.

I started over fresh overnight and got the same problem.

> Can you look to see that there is a line like this in all the vcxproj
> files under modules\proxy\balancers:
> <PropertyGroup><TrackFileAccess>false</TrackFileAccess></PropertyGroup>

Yes, next to last line right before the closing Project tag.

> The scripting that adds that bit is not really the greatest.  Perhaps
> it's failing for you for some reason.  One possibility here is a
> different version of Perl.  I'm using Perl 5.16.3.1603 from:
> http://www.activestate.com/activeperl/downloads

I am also using ActiveState.  5.12.2 in my case.

> If the above doesn't help, can you try the attached script (adjusting
> paths).  I know it's ugly it's basically just a find2perl script that
> I threw together to find failed builds while I was using this.  Just
> run it while the cd is the trunk and it should point out which bits of
> the build have Build FAILED in them.  You can then look at those logs
> and you should get a more detailed error.  You very well may only find
> what you've already found.

There were no attachments.

> The other comment I have is I did this on Windows 8 x64 (though I only
> built 32-bit binaries).  I'm not sure what version of Windows you're
> using, but this might be another possible source of issues.

Windows 7 x64, doing a 32-bit build.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Making the Windows Build Easier

Posted by Ben Reser <be...@reser.org>.
On Mon, May 6, 2013 at 4:47 PM, Mark Phippard <ma...@gmail.com> wrote:
> I have Update 2 installed.
> http://www.microsoft.com/en-us/download/details.aspx?id=38188

I've installed update 2, still get a completely finished build.

Can you look to see that there is a line like this in all the vcxproj
files under modules\proxy\balancers:
<PropertyGroup><TrackFileAccess>false</TrackFileAccess></PropertyGroup>

The scripting that adds that bit is not really the greatest.  Perhaps
it's failing for you for some reason.  One possibility here is a
different version of Perl.  I'm using Perl 5.16.3.1603 from:
http://www.activestate.com/activeperl/downloads

If the above doesn't help, can you try the attached script (adjusting
paths).  I know it's ugly it's basically just a find2perl script that
I threw together to find failed builds while I was using this.  Just
run it while the cd is the trunk and it should point out which bits of
the build have Build FAILED in them.  You can then look at those logs
and you should get a more detailed error.  You very well may only find
what you've already found.

The other comment I have is I did this on Windows 8 x64 (though I only
built 32-bit binaries).  I'm not sure what version of Windows you're
using, but this might be another possible source of issues.

Re: Making the Windows Build Easier

Posted by Mark Phippard <ma...@gmail.com>.
I have Update 2 installed. http://www.microsoft.com/en-us/download/details.aspx?id=38188

Sent from my iPad

On May 6, 2013, at 7:29 PM, Ben Reser <be...@reser.org> wrote:

> On Mon, May 6, 2013 at 3:40 PM, Mark Phippard <ma...@gmail.com> wrote:
>> I like that the script can be re-run.
> 
> Yes, I tried to make it smart enough to avoid redoing work that was
> already done.
> 
>> The script then started chugging along and building.  It looks like it
>> failed at the end of building httpd.  Not really sure why or what is
>> wrong:
>> 
>> ========== Build: 7 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
>> ========== Build: 118 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0
>> \Common7\IDE\devenv.COM"' : return code '0x1'
>> Stop.
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0
>> \VC\BIN\nmake.exe"' : return code '0x2'
>> Stop.
>> Failed building/installing httpd/apr/apu/api (exit code: 512) at build-svn-deps-
>> win.pl line 245.
>> 
>> Any ideas?  I searched the output for what Failed and do not see
>> anything referenced.
>> 
>> Searching for all instanced of "Error".  It might be this:
>> 
>> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.ta
>> rgets(347,5): error MSB6003: The specified task executable "CL.exe" could not be
>> run. The process cannot access the file 'C:\SVN\deps-1.8.x\build\httpd\modules\
>> proxy\balancers\Release\cl.write.1.tlog' because it is being used by another pro
>> cess.
> 
> The above error is a bug in the httpd build process related to newer
> versions of Visual Studio.  Since everything shares the same
> intermediate directories concurrent builds start blowing up over this
> log file.  The correct fix for this is to use different intermediate
> build directories for each module.  This is a major change to the
> httpd build system so I didn't do it.  Rather I applied a workaround
> by setting a flag that tells Visual Studio not to use the files that
> create the problem.
> 
> Let me see if I can reproduce this on my end.
> 
> What's the exact version of Visual Studio 2012 that you're using?  I'm
> on 11.0.50727.1.  I haven't bothered to apply the updates to it.

Re: Making the Windows Build Easier

Posted by Ben Reser <be...@reser.org>.
On Mon, May 6, 2013 at 3:40 PM, Mark Phippard <ma...@gmail.com> wrote:
> I like that the script can be re-run.

Yes, I tried to make it smart enough to avoid redoing work that was
already done.

> The script then started chugging along and building.  It looks like it
> failed at the end of building httpd.  Not really sure why or what is
> wrong:
>
> ========== Build: 7 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
> ========== Build: 118 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0
> \Common7\IDE\devenv.COM"' : return code '0x1'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0
> \VC\BIN\nmake.exe"' : return code '0x2'
> Stop.
> Failed building/installing httpd/apr/apu/api (exit code: 512) at build-svn-deps-
> win.pl line 245.
>
> Any ideas?  I searched the output for what Failed and do not see
> anything referenced.
>
> Searching for all instanced of "Error".  It might be this:
>
> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.ta
> rgets(347,5): error MSB6003: The specified task executable "CL.exe" could not be
>  run. The process cannot access the file 'C:\SVN\deps-1.8.x\build\httpd\modules\
> proxy\balancers\Release\cl.write.1.tlog' because it is being used by another pro
> cess.

The above error is a bug in the httpd build process related to newer
versions of Visual Studio.  Since everything shares the same
intermediate directories concurrent builds start blowing up over this
log file.  The correct fix for this is to use different intermediate
build directories for each module.  This is a major change to the
httpd build system so I didn't do it.  Rather I applied a workaround
by setting a flag that tells Visual Studio not to use the files that
create the problem.

Let me see if I can reproduce this on my end.

What's the exact version of Visual Studio 2012 that you're using?  I'm
on 11.0.50727.1.  I haven't bothered to apply the updates to it.