how to set current source directory relative to external project

classic Classic list List threaded Threaded
10 messages Options
Hex
Reply | Threaded
Open this post in threaded view
|

how to set current source directory relative to external project

Hex
hello CMake community,


I am experimenting with external projects. I have some files in an external project which are generated in `${CMAKE_SOURCE_DIR}`.


When I add the external project, however, it is using `${CMAKE_SOURCE_DIR}` of the external project.


I need `${CMAKE_SOURCE_DIR}` to be relative to the "super build", instead of the external project path.


Example:

message("${CMAKE_SOURCE_DIR} = /home/user/super")

ExternalProject_Add(ext1
    # directory options
    SOURCE_DIR      "${CMAKE_SOURCE_DIR}/ext1"
)


${CMAKE_SOURCE_DIR}/ext1/CMakeLists.txt:


message("${CMAKE_SOURCE_DIR} = /home/user/super/ext1")


The desired outcome would be to have the path /home/user/super in both messages. 
How can I do this?


thank you

--

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
Reply | Threaded
Open this post in threaded view
|

Re: how to set current source directory relative to external project

J Decker


On Tue, Jul 9, 2019 at 5:35 AM hex <[hidden email]> wrote:
hello CMake community,


I am experimenting with external projects. I have some files in an external project which are generated in `${CMAKE_SOURCE_DIR}`.


When I add the external project, however, it is using `${CMAKE_SOURCE_DIR}` of the external project.


I need `${CMAKE_SOURCE_DIR}` to be relative to the "super build", instead of the external project path.


Example:

message("${CMAKE_SOURCE_DIR} = /home/user/super")

ExternalProject_Add(ext1
    # directory options
    SOURCE_DIR      "${CMAKE_SOURCE_DIR}/ext1"
)


${CMAKE_SOURCE_DIR}/ext1/CMakeLists.txt:


message("${CMAKE_SOURCE_DIR} = /home/user/super/ext1")
 
message("${CMAKE_SOURCE_DIR}/.. = /home/user/super/ext1/..")  which == /home/user/super



The desired outcome would be to have the path /home/user/super in both messages. 
How can I do this?


thank you
--

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
Hex
Reply | Threaded
Open this post in threaded view
|

Re: how to set current source directory relative to external project

Hex

thank you J Decker for your reply.


Your suggestion does work but I want to preserve standalone use of the project, meaning that I want a reference to CMake source root directory.

Assuming there is only 1 hierarchy I could add an option:


if ( SUPERBUILD )

    message("${CMAKE_SOURCE_DIR}/.. = /home/user/super/ext1/..")

else ()

    message("${CMAKE_SOURCE_DIR} = /home/user/super/ext1")

endif ()


I think the better solution now is to make it relative to build directory and force out of source builds.


On 09/07/2019 14:26, J Decker wrote:

 
message("${CMAKE_SOURCE_DIR}/.. = /home/user/super/ext1/..")  which == /home/user/super



--

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
Reply | Threaded
Open this post in threaded view
|

Re: how to set current source directory relative to external project

J Decker


On Tue, Jul 9, 2019 at 9:38 AM hex <[hidden email]> wrote:

thank you J Decker for your reply.


Your suggestion does work but I want to preserve standalone use of the project, meaning that I want a reference to CMake source root directory.

Assuming there is only 1 hierarchy I could add an option:


if ( SUPERBUILD )

    message("${CMAKE_SOURCE_DIR}/.. = /home/user/super/ext1/..")

else ()

    message("${CMAKE_SOURCE_DIR} = /home/user/super/ext1")

endif ()


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)
 

On 09/07/2019 14:26, J Decker wrote:

 
message("${CMAKE_SOURCE_DIR}/.. = /home/user/super/ext1/..")  which == /home/user/super


--

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
Hex
Reply | Threaded
Open this post in threaded view
|

Re: how to set current source directory relative to external project

Hex
On 09/07/2019 18:25, J Decker wrote:

On Tue, Jul 9, 2019 at 9:38 AM hex <[hidden email]> 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.

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'. 

I could even set PREFIX "${CMAKE_SOURCE_DIR}/workspaces" which I'd actually prefer. 

The default binary directory is per project so I'd also change this to BINARY_DIR=${CMAKE_BINARY_DIR}

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
Reply | Threaded
Open this post in threaded view
|

Re: how to set current source directory relative to external project

J Decker


On Tue, Jul 9, 2019 at 1:24 PM hex <[hidden email]> wrote:
On 09/07/2019 18:25, J Decker wrote:

On Tue, Jul 9, 2019 at 9:38 AM hex <[hidden email]> 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
Hex
Reply | Threaded
Open this post in threaded view
|

Re: how to set current source directory relative to external project

Hex
This post was updated on .
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)



Exactly, these are mostly BYPRODUCTS, but also OUTPUT of build commands,
i.e. targets.



>     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 ?

Except for my generators, and I think I wasn't clear enough about this
part. I am using -G"Eclipse 2 - Unix Makefiles" for each external
project. Note that this leaves me with a Makefile for the "super build"
containing *all* targets of all projects. It *additionally* creates a
Makefile for each external project individually. So I can do stuff like:

/*cd build/ && make* # /to build the entire project or

*/cd build/workspaces/src/ext1-build/ && make/* # to build a specific
external project, /ext1./


This is what I am after -> a multi-workspace super build. By workspace
here I mean an eclipse workspace, the terminology does not exist in
CMake. Note that each project has its own root binary path, meaning that

${CMAKE_BINARY_DIR} = build # for super build

and

${CMAKE_BINARY_DIR} = build/workspaces/src/ext1-build # for external
project ext1


${CMAKE_CURRENT_BINARY_DIR} is then relative to any of either
${CMAKE_BINARY_DIR}'s.




--

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
J Decker wrote
On Tue, Jul 9, 2019 at 1:24 PM hex <[hidden email]> wrote:

> On 09/07/2019 18:25, J Decker wrote:
>
>
> On Tue, Jul 9, 2019 at 9:38 AM hex <[hidden email]> 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
J Decker wrote
On Tue, Jul 9, 2019 at 1:24 PM hex <[hidden email]> wrote:

> On 09/07/2019 18:25, J Decker wrote:
>
>
> On Tue, Jul 9, 2019 at 9:38 AM hex <[hidden email]> 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
J Decker wrote
On Tue, Jul 9, 2019 at 1:24 PM hex <[hidden email]> wrote:

> On 09/07/2019 18:25, J Decker wrote:
>
>
> On Tue, Jul 9, 2019 at 9:38 AM hex <[hidden email]> 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
Hex
Reply | Threaded
Open this post in threaded view
|

Re: how to set current source directory relative to external project

Hex

>   Except for my generators


well, to be exact it's not except for . I am using multiple generators which means multiple copies of build targets.



--

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
Hex
Reply | Threaded
Open this post in threaded view
|

Re: how to set current source directory relative to external project

Hex
When I use CMAKE_BINARY_DIR the problem remains. If I

set( EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin ) in my external project
the binary is placed in build/ext1-prefix/src/ext1-build/bin/.

Wouldn't it be better to have all my binaries in a single location? Such as
build/bin/ ? The only way I see to do this is to modify the paths in my
external projects to the parent directories, as has already been suggested.
Or copying them into that location after the build.

I don't think variables are propagated from the CMake project to the
external project.



--
Sent from: http://cmake.3232098.n2.nabble.com/
--

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
Reply | Threaded
Open this post in threaded view
|

Re: how to set current source directory relative to external project

Marc Herbert
In reply to this post by Hex
Le mar. 9 juil. 2019 à 13:24, hex <[hidden email]> a écrit :
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. 

How would CMake know that these tarballs are in a somewhat final version that you want to archive as opposed to a state where they haven't passed the most basic tests yet? I would implement this outside CMake: wherever is the information that guides the decision to archive. When that decision is made then some script would simply "exfiltrate" the tarballs and whatever else from the build/ directory before it gets cleaned. Sounds like something CI does every day.

This being said, CPack seems to have a ton of documented and undocumented (read: Stackoverflow) options, hopefully some of them do what you want.

Marc


--

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