<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 9, 2019 at 1:24 PM hex <<a href="mailto:hex7c3@gmail.com">hex7c3@gmail.com</a>> wrote:<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 bgcolor="#FFFFFF">
    <div class="gmail-m_-1691865451225767734moz-cite-prefix">On 09/07/2019 18:25, J Decker wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr"><br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Tue, Jul 9, 2019 at 9:38
            AM hex <<a href="mailto:hex7c3@gmail.com" target="_blank">hex7c3@gmail.com</a>> wrote:<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 bgcolor="#FFFFFF"><br>
              <p>I think the better solution now is to make it relative
                to build directory and force out of source builds. <br>
              </p>
              <p><br>
              </p>
            </div>
          </blockquote>
          <div>+1 I think; You said it was generated?  It should be in
            the build directory anyway :) <br>
          </div>
          <div>And out of source always.  (makes it easier to source
            version control)</div>
          <div> <br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>Now that I look at it it seems very obvious. I still have doubts,
      though:</p>
    <p>I guess I am seeing the contents of a build directory as somewhat
      volatile. For most files I want that, to either clean the project
      or override the files. <br>
    </p>
    <p>But what about files I want to archive, such as a tarball or
      zipped documentation: does it make sense to place them into the
      build directory? The files belong to the project, though are not
      source controlled but aren't install targets either. <br></p></div></blockquote><div>I don't know what sorts of files those are; they don't exist but they get created, they're not tracked, and not installed...</div><div>They sounds like a build product, which is a target, (even it it's just part of a product, it's still a target)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><p>
    </p>
    <p>Another thing I noticed is that my CMAKE_GENERATOR are now buried
      in subfolders. To change that I set PREFIX
      "${CMAKE_BINARY_DIR}/workspaces". Now all external projects are
      using the same prefix and are therefore generated into the same
      directory 'workspaces'. </p></div></blockquote><div>right ? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <p>I could even set PREFIX "${CMAKE_SOURCE_DIR}/workspaces" which
      I'd actually prefer. </p></div></blockquote><div>that makes it an insource product, which, if it's not in source control shouldn't be in the source.... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <p>The default binary directory is per project so I'd also change
      this to BINARY_DIR=${CMAKE_BINARY_DIR}<br></p></div></blockquote><div>there's CMAKE_CURRENT_BINARY_DIR and that's per project, otherwise CMAKE_BINARY_DIR is a constant for all things within a single cmake invocation.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><p>
    </p>
    <p>I'm not concerned about <i>how</i> to do it but rather <i>if</i>
      it should be done. The documentation recommends to stick with the
      defaults. <br>
    </p>
    <p><br>
    </p>
    <p>Any thoughts on this?<br>
    </p>
  </div>

-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://cmake.org/mailman/listinfo/cmake" rel="noreferrer" target="_blank">https://cmake.org/mailman/listinfo/cmake</a><br>
</blockquote></div></div>