On Tue, Jul 9, 2019 at 1:24 PM hex <hex...@gmail.com> wrote:
> On 09/07/2019 18:25, J Decker wrote:
>
>
> On Tue, Jul 9, 2019 at 9:38 AM hex <hex...@gmail.com> wrote:
>
>>
>> I think the better solution now is to make it relative to build directory
>> and force out of source builds.
>>
>>
>> +1 I think; You said it was generated? It should be in the build
> directory anyway :)
> And out of source always. (makes it easier to source version control)
>
>
> Now that I look at it it seems very obvious. I still have doubts, though:
>
> 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.
>
> 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.
>
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...
They sounds like a build product, which is a target, (even it it's just
part of a product, it's still a target)
> 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'.
>
right ?
> I could even set PREFIX "${CMAKE_SOURCE_DIR}/workspaces" which I'd
> actually prefer.
>
that makes it an insource product, which, if it's not in source control
shouldn't be in the source....
> The default binary directory is per project so I'd also change this to
> BINARY_DIR=${CMAKE_BINARY_DIR}
>
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.
> I'm not concerned about *how* to do it but rather *if* it should be done.
> The documentation recommends to stick with the defaults.
>
>
> Any thoughts on this?
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
--
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:
https://cmake.org/mailman/listinfo/cmake
