<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Le mer. 14 nov. 2018 à 13:25, Poughon Victor <<a href="mailto:Victor.Poughon@cnes.fr">Victor.Poughon@cnes.fr</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="FR">
<div class="gmail-m_-7466573677791448557WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif">Yes you are correct on all your observations. We already use ninja and ccache wherever we can. In fact we have an issue about the whole
 end-to-end build performance where we track all effort on this throughout the project (if you're interested:
<a href="https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues/1649" target="_blank">https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues/1649</a>)</span></p></div></div></blockquote><div><br></div><div>End-to-end build performance is a subject of interest to me, I'll have a look. </div><div><span style="font-family:Calibri,sans-serif;font-size:11pt"> </span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="FR"><div class="gmail-m_-7466573677791448557WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif">There are indeed quick and easy wins to be had with those tools (and we are working on it). But my original question is not about that.
 It's about speeding up the configure step with makefile generator. I still don't think it's normal that it does hundreds of thousands of I/O on files that are a few bytes or even empty. However it's possible that it's because we do something incorrect in our
 CMakeLists.txt and not CMake's fault.</span></p></div></div></blockquote><div><br></div><div>I don't really know makefile-generator internals so I cannot tell.</div><div>For sur the current OTB build dir constructed with Makefile generator is spitting out around 180 Makefile.</div><div>May be you can profile the cmake execution by building a debug version of CMake and collect more precise insight on where the bottlenecks may reside.</div><div><br></div><div>You may track try_compile which could obviously be slow and may be configure_file as well.</div><div>Otherwise I don't know, I guess you'll have to profile the cmake run. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="FR"><div class="gmail-m_-7466573677791448557WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif">It's true that a few minutes of configure is not much when doing a full build, but consider incremental builds where all you do is change
 one cxx file (and cmake is triggered because you changed git branch or something). Then the generate step is a significant part of the time you wait.</span></p></div></div></blockquote><div><br></div><div>Yes that right.</div><div>Note however that changing git branch should nor per-se trigger a cmake run.</div><div>Only changing a CMakeLists.txt or configured file or explicitely specified by</div><div>CMAKE_CONFIGURE_DEPENDS.<br></div><div><br></div><div>Otherwise changing branch with git that only modifies source shouldn't trigger cmake rebuild.</div><div>I do that all the time in a classical git branch dev model.</div><div><br></div><div><br></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eric<br></div></div></div></div></div></div></div>