[prev in list] [next in list] [prev in thread] [next in thread]
List: cmake
Subject: [CMake] Using the "Visual Studio 10 Win64" CMake generator of CMake 2.8.12.2,
From: Dominique Ledit <Dominique.Ledit () PDGM ! com>
Date: 2014-09-25 16:55:55
Message-ID: 31e29a82bc4340bfa948fc31a0959e17 () DM2PR0701MB1344 ! namprd07 ! prod ! outlook ! com
[Download RAW message or body]
Hi
I use CMake 2.8.12.2 and the "Visual Studio 10 Win64" generator to generate=
the solution/projects I use to build my application.
My Windows development platform is a Win 7 machine with Visual Studio 10 in=
stalled on it.
I'm currently trying to address an issue that makes many .dll/.exe being li=
nked on Windows platform, using msbuild, even if they should not do. I've =
read a lot of articles and done a lot of tests on small projects and
it seems that, using msbuild, the dependencies are managed by the build sys=
tem itself through the use of Tracker.exe that parses the link command line=
s to retrieve the dependencies.
1. The library dependencies in the VS solution generated by CMake are=
correct. At least they are consistent with what Microsoft thinks is the ri=
ght way to build a product on their platform. The .dll/.exe depend on the .=
lib (import lib) of their direct dependencies.
2. In debug builds I perform incremental links. This means that the b=
uild of a library doesn't necessary result in a change of the .lib: Assumin=
g there were no changes in the symbol table (no changes in the library API)=
the .lib is left unchanged. So, typically, as far as we don't change the A=
PI (.h) the .dll is changed but the .lib is left unchanged. So theoreticall=
y a change that doesn't affect the API will result in the library being reb=
uilt, but the .lib is left unchanged, and the products that depend on this =
library (through the .lib) are not re-built. This is close to the behavior =
on Linux, where there is no dependencies between .so, but the builds are tr=
iggered if the API changes because basically some .h changed, which trigger=
s some .o builds in the dependent libraries, hence the libs rebuild.
3. So basically everything looks consistent and neat.
Now here is the issue as far as I understand: whenever a library has to reb=
uild because one of the .lib it depends on changed, the incremental link is=
disabled, a full link is performed and, as a consequence, the .lib (import=
lib) is changed, even if there is no reason for it to change (the API has =
not changed). And then all the libraries that depend on it are rebuilt, wit=
h incremental link disabled, which cascades again and results in all the de=
pendent libs (direct and indirect) rebuilding.
The trick I've found is to disable the tracker, by setting the TrackFileAcc=
ess property to "false" (I add <PropertyGroup><TrackFileAccess>false</ Trac=
kFileAccess></ PropertyGroup>) in each .vcxproj generated at configuration =
time. Of course this has to be done after each CMake configure.
So my question is:
is there a way to make the "Visual Studio 10 Win64" generator set this prop=
erty to false, in all .vcxproj at generation time?
Thank you very much
Dominique
------------------- This e-mail, including any attached files, may contain =
confidential and privileged information for the sole use of the intended re=
cipient. Any review, use, distribution, or disclosure by others is strictly=
prohibited. If you are not the intended recipient (or authorized to receiv=
e information for the intended recipient), please contact the sender by rep=
ly e-mail and delete all copies of this message.
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:680158123;
mso-list-template-ids:-1153521404;}
@list l1
{mso-list-id:904219368;
mso-list-type:hybrid;
mso-list-template-ids:-1028863446 67698689 67698691 67698693 67698689 67698691 \
67698693 67698689 67698691 67698693;} @list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I use CMake 2.8.12.2 and the “Visual Studio 10 \
Win64” generator to generate the solution/projects I use to build my \
application.<o:p></o:p></p> <p class="MsoNormal">My Windows development platform is a \
Win 7 machine with Visual Studio 10 installed on it.<o:p></o:p></p> <p \
class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">I’m currently \
trying to address an issue that makes many .dll/.exe being linked on Windows \
platform, using msbuild, even if they should not do. I’ve read a lot of \
articles and done a lot of tests on small projects and <o:p></o:p></p>
<p class="MsoNormal">it seems that, using msbuild, <span style="color:black">the \
dependencies are managed by the build system itself through the use of Tracker.exe \
that parses the link command lines to retrieve the dependencies</span><span \
style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" \
style="margin-left:0in;text-indent:-.25in;line-height:12.75pt;mso-list:l0 level1 \
lfo1"> <![if !supportLists]><span style="color:black"><span \
style="mso-list:Ignore">1.<span style="font:7.0pt "Times New \
Roman""> \
</span></span></span><![endif]><span style="color:black">The library dependencies in \
the VS solution generated by CMake are correct. At least they are consistent with \
what Microsoft thinks is the right way to build a product on their platform. The \
.dll/.exe depend on the .lib (import lib) of their direct \
dependencies.<o:p></o:p></span></p> <p class="MsoNormal" \
style="margin-left:0in;text-indent:-.25in;line-height:12.75pt;mso-list:l0 level1 \
lfo1"> <![if !supportLists]><span style="color:black"><span \
style="mso-list:Ignore">2.<span style="font:7.0pt "Times New \
Roman""> \
</span></span></span><![endif]><span style="color:black">In debug builds I perform \
incremental links. This means that the build of a library doesn't necessary result in \
a change of the .lib: Assuming there were no changes in the symbol table (no changes \
in the library API) the .lib is left unchanged. So, typically, as far as we don't \
change the API (.h) the .dll is changed but the .lib is left unchanged. So \
theoretically a change that doesn't affect the API will result in the library being \
rebuilt, but the .lib is left unchanged, and the products that depend on this \
library (through the .lib) are not re-built. This is close to the behavior on Linux, \
where there is no dependencies between .so, but the builds are triggered if the API \
changes because basically some
.h changed, which triggers some .o builds in the dependent libraries, hence the libs \
rebuild. <o:p></o:p></span></p>
<p class="MsoNormal" \
style="margin-left:0in;text-indent:-.25in;line-height:12.75pt;mso-list:l0 level1 \
lfo1"> <![if !supportLists]><span style="color:black"><span \
style="mso-list:Ignore">3.<span style="font:7.0pt "Times New \
Roman""> \
</span></span></span><![endif]><span style="color:black">So basically everything \
looks consistent and neat. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:12.0pt;line-height:12.75pt"><span \
style="color:black">Now here is the issue as far as I understand: whenever a library \
has to rebuild because one of the .lib it depends on changed, the incremental link is \
disabled, a full link is performed and, as a consequence, the .lib (import lib) is \
changed, even if there is no reason for it to change (the API has not changed). And \
then all the libraries that depend on it are rebuilt, with incremental link disabled, \
which cascades again and results in all the dependent libs (direct and indirect) \
rebuilding.<o:p></o:p></span></p> <p class="MsoNormal" \
style="margin-top:12.0pt;line-height:12.75pt"><span style="color:black">The trick \
I’ve found is to disable the tracker, by setting the TrackFileAccess property \
to “false” (I add <PropertyGroup><TrackFileAccess>false</ \
TrackFileAccess></ PropertyGroup>) in each .vcxproj generated at \
configuration time. Of course this has to be done after each CMake configure. \
<o:p></o:p></span></p> <p class="MsoNormal" \
style="margin-top:12.0pt;line-height:12.75pt"><span style="color:black">So my \
question is: <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:12.0pt;line-height:12.75pt"><span \
style="color:black">is there a way to make the “Visual Studio 10 Win64” \
generator set this property to false, in all .vcxproj at generation \
time?<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="color:black"><o:p> </o:p></span></p> <p class="MsoNormal"><span \
style="color:black">Thank you very much <o:p></o:p></span></p> <p \
class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span style="color:black">Dominique</span><o:p></o:p></p> </div>
------------------- This e-mail, including any attached files, may contain \
confidential and privileged information for the sole use of the intended recipient. \
Any review, use, distribution, or disclosure by others is strictly prohibited. If you \
are not the intended recipient (or authorized to receive information for the \
intended recipient), please contact the sender by reply e-mail and delete all copies \
of this message. </body>
</html>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at: \
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more information \
on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at \
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--===============1989079665==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic