Header only libraries with code generated files...

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

Header only libraries with code generated files...

Malfettone, Kris

Hi all,

I had a question about managing code generated header only libraries is a very large project.  Currently, we have a very large project with many static and many generated files.  The problem I have is that due to the size of the project many usages (exe’s and libraries) of those code generated files (header files) are done in separate folders from the generation targets.  That leads me to have to be very careful and explicit with using add_custom_command(…), add_custom_target(…), add_depenendcies(…), and set_source_files_properties( … PROPERTIES GENERATED TRUE ).  Most of that knowledge / setup modeled after reading https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/

 

I was wondering if I was able to simplify that by using Interface Libraries and doing target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES ).  I guess my concerns were when adding the interface library to a target in another folder would I still have to:

·         Manually add the transitive dependencies

·         Manually indicate that the generated files are code generated.

 

 

I am also assuming my setup would be something like this when using Interface Libraries….

1.       Still use add_custom_command/add_custom_target to do the generation steps.

2.       Add the interface library in the same folder as the generation steps, managing its relationship with the code generation target via add_dependencies() meaning most of the code generation quirks are avoided.

3.       When adding executables or libraries in other folders just use target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES )

a.       Hoping that any transitive dependencies to the code generation steps would be handled by exe_name being dependent on MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES

b.      Also hoping that I wouldn’t have to specify which files are code generated at that step

 

I hope this makes sense. 

 

-Kris




IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

--

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: Header only libraries with code generated files...

Kyle Edwards
It sounds like you want to use the INTERFACE version of
target_include_directories():
https://cmake.org/cmake/help/latest/command/target_include_directories.html

What this means is "anything that links against interface library foo
will also need to add these paths to its include directories."

You will also want to use add_dependencies() to make the interface
library dependent on the generation steps:

https://cmake.org/cmake/help/latest/command/add_dependencies.html

Kyle

On Fri, Jun 28, 2019 at 11:17 AM Malfettone, Kris
<[hidden email]> wrote:

>
> Hi all,
>
> I had a question about managing code generated header only libraries is a very large project.  Currently, we have a very large project with many static and many generated files.  The problem I have is that due to the size of the project many usages (exe’s and libraries) of those code generated files (header files) are done in separate folders from the generation targets.  That leads me to have to be very careful and explicit with using add_custom_command(…), add_custom_target(…), add_depenendcies(…), and set_source_files_properties( … PROPERTIES GENERATED TRUE ).  Most of that knowledge / setup modeled after reading https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/
>
>
>
> I was wondering if I was able to simplify that by using Interface Libraries and doing target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES ).  I guess my concerns were when adding the interface library to a target in another folder would I still have to:
>
> ·         Manually add the transitive dependencies
>
> ·         Manually indicate that the generated files are code generated.
>
>
>
>
>
> I am also assuming my setup would be something like this when using Interface Libraries….
>
> 1.       Still use add_custom_command/add_custom_target to do the generation steps.
>
> 2.       Add the interface library in the same folder as the generation steps, managing its relationship with the code generation target via add_dependencies() meaning most of the code generation quirks are avoided.
>
> 3.       When adding executables or libraries in other folders just use target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES )
>
> a.       Hoping that any transitive dependencies to the code generation steps would be handled by exe_name being dependent on MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES
>
> b.      Also hoping that I wouldn’t have to specify which files are code generated at that step
>
>
>
> I hope this makes sense.
>
>
>
> -Kris
>
>
> ________________________________
>
> IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
> --
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Header only libraries with code generated files...

Malfettone, Kris
I agree that is sounds like the right way and it is what I would like to use.  However, before going through the work I just wanted to make sure it didn't suffer from the same quirks that add_custom_target does when dealing with code generation in different directory.  As outlined in this blog post:

https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/

-Kris

-----Original Message-----
From: Kyle Edwards [mailto:[hidden email]]
Sent: Friday, June 28, 2019 11:31 AM
To: Malfettone, Kris <[hidden email]>
Cc: [hidden email]
Subject: Re: [CMake] Header only libraries with code generated files...

It sounds like you want to use the INTERFACE version of
target_include_directories():
https://cmake.org/cmake/help/latest/command/target_include_directories.html

What this means is "anything that links against interface library foo
will also need to add these paths to its include directories."

You will also want to use add_dependencies() to make the interface
library dependent on the generation steps:

https://cmake.org/cmake/help/latest/command/add_dependencies.html

Kyle

On Fri, Jun 28, 2019 at 11:17 AM Malfettone, Kris
<[hidden email]> wrote:

>
> Hi all,
>
> I had a question about managing code generated header only libraries is a very large project.  Currently, we have a very large project with many static and many generated files.  The problem I have is that due to the size of the project many usages (exe’s and libraries) of those code generated files (header files) are done in separate folders from the generation targets.  That leads me to have to be very careful and explicit with using add_custom_command(…), add_custom_target(…), add_depenendcies(…), and set_source_files_properties( … PROPERTIES GENERATED TRUE ).  Most of that knowledge / setup modeled after reading https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/
>
>
>
> I was wondering if I was able to simplify that by using Interface Libraries and doing target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES ).  I guess my concerns were when adding the interface library to a target in another folder would I still have to:
>
> ·         Manually add the transitive dependencies
>
> ·         Manually indicate that the generated files are code generated.
>
>
>
>
>
> I am also assuming my setup would be something like this when using Interface Libraries….
>
> 1.       Still use add_custom_command/add_custom_target to do the generation steps.
>
> 2.       Add the interface library in the same folder as the generation steps, managing its relationship with the code generation target via add_dependencies() meaning most of the code generation quirks are avoided.
>
> 3.       When adding executables or libraries in other folders just use target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES )
>
> a.       Hoping that any transitive dependencies to the code generation steps would be handled by exe_name being dependent on MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES
>
> b.      Also hoping that I wouldn’t have to specify which files are code generated at that step
>
>
>
> I hope this makes sense.
>
>
>
> -Kris
>
>
> ________________________________
>
> IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
> --
>
> 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

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
--

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