<div>If that is what people want, there is a cache variable that could be set to disable the error for other automated builds. If it is a warning then it it more likely to be missed, which is why we made it an error in Titan (unless the cache variable is set).</div>

<div><br></div><div>Marcus</div><br><div class="gmail_quote">On Tue, Jun 29, 2010 at 4:43 PM, pat marion <span dir="ltr"><<a href="mailto:pat.marion@kitware.com">pat.marion@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I think it should be a regular message and not a SEND_ERROR though.  There are lots of ways that people automate builds besides CTest.<br><font color="#888888"><br>Pat<br><br></font><div class="gmail_quote"><div><div></div>

<div class="h5">On Tue, Jun 29, 2010 at 4:27 PM, Marcus D. Hanwell <span dir="ltr"><<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div><div></div><div class="h5"><div class="gmail_quote">So, I was thinking about this over the weekend, and talked to Brad King. There is an environment variable that is set by CTest when it drives the build. I can check if that variable is defined, and know that CTest is driving the build.</div>




<div class="gmail_quote"><br></div><div class="gmail_quote">If I did that then when a user first configures VTK CMake will print an error with copy/paste instructions to check out the local hooks (along with a link to the wiki). They can set a CMake cache variable to ignore the hooks to get past it if they wish. If you are not in a git checkout the whole process is skipped.</div>




<div class="gmail_quote"><br></div><div class="gmail_quote">If CTest invoked the configure then the environment variable is set, and so the error is not raised - negating the need to set a cache variable on all of the dashboard machines. The only assumption is that CTest is driving the build, which I think is reasonable. I tested the logic out in Titan and it looks good.</div>




<div class="gmail_quote"><br></div><div class="gmail_quote">Does this cover all of your requirements reasonably? I will be checking this code into Titan as I think it is an improvement on what we had there too. I would be happy to check the relevant portion into VTK.</div>




<div class="gmail_quote"><br></div><font color="#888888"><div class="gmail_quote">Marcus</div></font><div><div></div><div><div class="gmail_quote"><br></div><div class="gmail_quote">On Thu, Jun 17, 2010 at 6:33 PM, Moreland, Kenneth <span dir="ltr"><<a href="mailto:kmorel@sandia.gov" target="_blank">kmorel@sandia.gov</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">




<div><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
In short, a pushurl is not a good indication of whether commits will be made or whether those commits will eventually be pushed to the main repository.<br>
<br>
-Ken<div><div></div><div><br>
<br>
<br>
On 6/17/10 2:46 PM, "Marcus D. Hanwell" <<a href="http://marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>> wrote:<br>
<br>
</div></div></span></font><div><div></div><div><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">On Thu, Jun 17, 2010 at 4:40 PM, Clinton Stimpson <<a href="http://clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>> wrote:<br>





</span></font><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
Can you key off the existence of a pushurl?<br>
But I also wonder how this would keep the hooks updated?<br>
</span></font></blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
We could possibly be clever and do a little regex to check for the git@ form of the url/pushurl. I hadn't considered being that sneaky, but it sound like a viable approach and would ease the dashboard pain.<br>
<br>
Marcus<br>
</span></font><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
On Thursday, June 17, 2010 02:13:37 pm Marcus D. Hanwell wrote:<br>
> On Thu, Jun 17, 2010 at 4:06 PM, Moreland, Kenneth <<a>kmorel@sandia.gov>wrote</a>:<br>
> >  That’s a good point about CMake modifying the source tree, but I think<br>
> ><br>
> > this is one of those cases we should let the rule slide.  In this case we<br>
> > are installing what, IMHO, git should be pulling for us.  Although the<br>
> > Wiki says its optional, it really should be enforced for anyone who<br>
> > makes any commit to any repository.<br>
><br>
> We came to a similar conclusion in Titan, but I am not sure about letting<br>
> the rule slide. This is new territory though, and it is just my take<br>
><br>
> > I’m less thrilled about the “error if not installed” option because it<br>
> > still pushes the responsibility back on every developer.  It could also<br>
> > wreck havoc on the dashboards as there will be a delay in getting someone<br>
> > to fix the warning.  But if that is the general consensus, it’s way<br>
> > better than what we have now, which is nothing.  If that is the path we<br>
> > choose to<br>
> ><br>
> > follow, then I would hope that the following could be be features:<br>
> >    - CMake be very insistent about installing the hooks.  It should not<br>
> >    be easy to miss or ignore the error.<br>
> >    - The error should give clear instructions on how to install the<br>
> >    hooks.<br>
> ><br>
> >     It’s annoying to have to find it in the Wiki every time.<br>
> ><br>
> >    - The check should also look for any updates to the hooks in addition<br>
> >    to just seeing if they are installed.  One of the problems I run into<br>
> >    is that even though I try to be diligent about installing hooks, I<br>
> >    miss changes pushed to the repository.<br>
> >    - The check should turn itself off if not run in a git repository.  A<br>
> >    user who downloaded the source from the web would never be able to<br>
> >    satisfy the requirement.<br>
><br>
> The checks in Titan have all but the third feature. That would be a<br>
> valuable general addition though, and I think there is some code floating<br>
> around that could help us to accomplish this. It would be good to hear how<br>
> others feel about this, but we should certainly be making these things as<br>
> easy as possible for our developers. I will see what our software process<br>
> type people think - Brad, Dave, Bill?<br>
><br>
> Marcus<br>
> --<br>
> Marcus D. Hanwell, Ph.D.<br>
> R&D Engineer, Kitware Inc.<br>
> (518) 881-4937<br>
</span></font></blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
<br>
</span></font></blockquote>
</div></div></div>


</blockquote></div><br>
</div></div><br></div></div><div class="im">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
<br></div></blockquote></div><br>
</blockquote></div><br>