Bert Huijben <[email protected]> писал в своём письме Tue, 04 Sep 2012
04:22:46 +0400:
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: maandag 3 september 2012 21:19
To: [email protected]
Subject: svn commit: r1380311 -
/subversion/trunk/build/generator/templates/svn_locale.vcxproj.ezt
Author: rdonch
Date: Mon Sep 3 19:19:01 2012
New Revision: 1380311
URL: http://svn.apache.org/viewvc?rev=1380311&view=rev
Log:
* build/generator/templates/svn_locale.vcxproj.ezt: Change the
configuration
type to "Makefile", otherwise the generated project doesn't do
anything.
(Obvious fix.)
Why didn't the utility project work for you?
What didn't work?
(Which Visual Studio version?)
This configuration (and other projects with the same setting) worked for
a few years in a number of setups now.
I think both CollabNet's and Wandisco's current 1.7 releases are built
using this version of the template, but I think both with gettext
disabled.
Maybe with a bit more knowledge about your scenario the fix is obvious,
but currently it isn't for me. And I'm surprised the original script
didn't work.
Sure, I'll show you:
src-trunk> svn diff
Index: build/generator/templates/svn_locale.vcxproj.ezt
===================================================================
--- build/generator/templates/svn_locale.vcxproj.ezt (revision 1380311)
+++ build/generator/templates/svn_locale.vcxproj.ezt (working copy)
@@ -32,7 +32,7 @@
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
[for platforms][for configs] <PropertyGroup
Condition="'$(Configuration)|$(Platform)'=='[configs]|[platforms]'"
Label="Configuration">
- <ConfigurationType>Makefile</ConfigurationType>
+ <ConfigurationType>Utility</ConfigurationType>
<CLRSupport>false</CLRSupport>
<PlatformToolset>[toolset_version]</PlatformToolset>
</PropertyGroup>
src-trunk> :: This is the old version...
src-trunk> del build\win32\vcnet-vcproj\svn_locale.vcxproj
src-trunk> python gen-make.py --reload
BDB not found, BDB fs will not be built
Generating for Visual Studio 2012
Could not detect Ruby version, assuming 1.8.
Ruby bindings will be linked with msvcrt-ruby18.lib
Found installed perl version number.
Perl bindings will be linked with perl516.lib
Found installed SWIG version 2.0.8
Using SWIG library directory C:\Soft32NoSpaces\SWIG\Lib
Found JDK version 1.7 in C:\Program Files\Java\JDK
Found SQLite version 3.7.13
Found ZLib version 1.2.7
Found serf version 1.1.0
Wrote: build\win32\vcnet-vcproj\svn_locale.vcxproj
src-trunk> devenv subversion_vcnet.sln /Build Release /Project locale
Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.50727.1.
Copyright (C) Microsoft Corp. All rights reserved.
1>------ Build started: Project: locale, Configuration: Release x64 ------
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
src-trunk> dir /B Release\mo
BuildLog_locale.htm
src-trunk> :: Nothing was built. Now let's try the new version...
src-trunk> svn revert build\generator\templates\svn_locale.vcxproj.ezt
Reverted 'build\generator\templates\svn_locale.vcxproj.ezt'
src-trunk> python gen-make.py --reload
[Found the same stuff...]
Wrote: build\win32\vcnet-vcproj\svn_locale.vcxproj
src-trunk> devenv subversion_vcnet.sln /Build Release /Project locale
Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.50727.1.
Copyright (C) Microsoft Corp. All rights reserved.
1>------ Build started: Project: locale, Configuration: Release x64 ------
1> Подпапка или файл ..\..\Release\mo уже существует.
1> Running msgfmt on de.po...
1> Running msgfmt on es.po...
1> Running msgfmt on fr.po...
1> Running msgfmt on it.po...
1> Running msgfmt on ja.po...
1> Running msgfmt on ko.po...
1> Running msgfmt on nb.po...
1> Running msgfmt on pl.po...
1> Running msgfmt on pt_BR.po...
1> Running msgfmt on sv.po...
1> Running msgfmt on zh_CN.po...
1> Running msgfmt on zh_TW.po...
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
src-trunk> dir /B Release\mo
BuildLog_locale.htm
de.mo
es.mo
fr.mo
it.mo
ja.mo
ko.mo
nb.mo
pl.mo
pt_BR.mo
sv.mo
zh_CN.mo
zh_TW.mo
I thought the fix was obvious because the presence of the
NMake*CommandLine elements indicates it ought to be a Makefile project
(cf. zlib.vcxproj.ezt); but if you think I'm overstepping my boundaries
here, then sure, I'll go through you next time.
Roman.
