Re: [cmake-developers] Error handling in dashboard scripts
On 05/25/2018 04:27 PM, Kyle Edwards wrote: > ctest_start() > ctest_configure() > ctest_build() > ctest_test() > ctest_submit() > > What happens if ctest_configure() fails (for example, because CMake > failed to find a needed library)? Does the entire script stop right > there? Or does it continue and try to execute ctest_build() anyway? IIRC it just moves on to each command in sequence and does what that command would normally do, letting it fail as it may given whatever state in the build tree is left behind by earlier failures, if any. Unless the failure is so bad that ctest_submit hasn't been told where to submit the results it should always be reached. -Brad -- 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-developers
Re: [cmake-developers] How to handle dependencies of protobuf files ?
On 05/15/2018 03:45 PM, Alexander Neundorf wrote: > I think to do it properly, there would have to be a dependency scanning for > proto files like there is for C/C++ headers. In order to handle implicit dependencies like that implied by import "MyBase.proto"; then they would somehow need to be extracted from source content. Ideally protoc should be able to write a depfile as a side effect. Otherwise all dependencies should be listed explicitly somewhere. -Brad -- 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-developers
[cmake-developers] Proposed new CMake module FindITT.cmake
Hi All, I'd like to maintain new finding module for ITT (Instrumentation and Tracing Technology) library. You may find more details about ITT at https://github.com/intel/IntelSEAPI/wiki or at https://software.intel.com/en-us/node/544195. Please let me know if I need to provide more details. Proposed module is here: https://github.com/dmitry-gurulev/cmake/blob/master/FindITT.cmake PS Although IntelSEAPI (which contains ITT sources) is a CMake based library, ITT itself might be used as standalone binary library, so finding module still makes sense. BTW, I'm going to propose CMake package configuration file for SEAPI, as it is recommended at https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/dev/Module-Maintainers Joint Stock Company Intel A/O Registered legal address: Krylatsky Hills Business Park, 17 Krylatskaya Str., Bldg 4, Moscow 121614, Russian Federation This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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-developers
Re: [cmake-developers] Proposed new CMake module FindITT.cmake
On 05/29/2018 10:30 AM, Gurulev, Dmitry wrote: > Although IntelSEAPI (which contains ITT sources) is a CMake based > library, ITT itself might be used as standalone binary library, so > finding module still makes sense If the upstream is CMake-friendly it should provide a CMake Package Configuration File with its SDK along with the headers and libraries. See documentation here: https://cmake.org/cmake/help/v3.11/manual/cmake-packages.7.html That will allow `find_package` to work without any find module and without guessing which headers and libraries match. Thanks, -Brad -- 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-developers
[cmake-developers] Unit testing CMake modules
Hi all,
We have a rather large amount of CMake code (4k+ lines) in various
modules/functions. They contain the common logic for many of our
projects. This makes it quite an important base for everything our team
does.
Rather shamefully at present these modules are rather poorly tested. I'd
like to improve this, but the current way of testing CMake code
is typically to run a trimmed project, and to verify whether certain
invocations produce a certain output or file hierarchy.
This involves a bit of infrastructure and can be a bit cumbersome
maintain, to diagnose when tests fail, and it requires a separate run of
the tests.
The overall cumbersomeness of the setup in turn discourages in our team,
including myself, from adding tests.
I'd like a more integrated approach that makes running at least some
basic tests part of the build progress, and a more direct way of
reporting failures.
In other programming environments, testing often involves some kind of
mocking environment, and CMake helpfully allows the overriding of CMake
built in functions, though this is typically discouraged.
In my ideal world it would be possible to save the state of the current
function set up, then call a function with a certain given number of
parameters, and expect a certain sequence of events, such as functions
to be called, environment variables to be set, etc.
Something akin to CMakePushCheckState, except for built in functions.
Then a module could provide for some functions that would set up
expectations and verify them, within a run of cmake, or possibly some
other commands could be added, to give some syntactic glossy coat to it.
As it wouldn't actually trigger any of the expensive generating
functions, it would be lightweight, quick to run and give pretty direct
errors in terms of failed expectations, reducing debug time.
If it was done with CMake commands, I might imagine it to look something
like:
function(foobar)
# function to test, does something non trivial
if ("FOO" IN_LIST ARGV)
install(FILES foo DESTINATION foo_dir)
else("BAR" IN_LIST ARGV)
message(FATAL_ERROR "Some error")
else("BAZ" IN_LIST ARGV)
set(BAZ True PARENT_SCOPE)
endif()
endfunction()
test(foobar)
expect(WITH "FOO" CALL install FILES foo DESTINATION foo_dir)
expect(WITH "BAR" CALL message FATAL_ERROR "Some error")
expect(WITH "BAZ" ENVIRONMENT BAZ True)
endtest(foobar)
What do people think? Is this crazy? Is there a quicker way to get
somewhere close? Should I put some effort into making this into an
actual proposal/working code?
Thanks in advance,
W
This transmission contains information that may be confidential and contain
personal views which are not necessarily those of YouView TV Ltd. YouView TV
Ltd (Co No:7308805) is a limited liability company registered in England and
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames
Street, London, EC3R 6YT. For details see our web site at http://www.youview.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-developers
Re: [cmake-developers] How to handle dependencies of protobuf files ?
Hi, On 2018 M05 29, Tue 09:52:16 CEST Brad King wrote: > On 05/15/2018 03:45 PM, Alexander Neundorf wrote: > > I think to do it properly, there would have to be a dependency scanning > > for > > proto files like there is for C/C++ headers. > > In order to handle implicit dependencies like that implied by > > import "MyBase.proto"; > > then they would somehow need to be extracted from source content. > Ideally protoc should be able to write a depfile as a side effect. Parsing them using cmake would more or less work, also the include dirs are known, so technically this would probably work. But the parsing would happen at cmake-time, not at compile-time, but editing a proto-file does not trigger a cmake run... Would that have to be implemented similar to the C dependency scanning ? > Otherwise all dependencies should be listed explicitly somewhere. so the cheap solution would be to add an argument to PROTOBUF_GENERATE_CPP() to list proto-files these proto-files depend on which is forwarded to (every) add_custom_command() call inside PROTOBUF_GENERATE_CPP(). Not very elegant, but at least it would make it work correctly. This would require that if in a set of proto-files there are different dependencies, for each of those with different dependencies a separate PROTOBUF_GENERATE_CPP() would be needed. A bit ugly, but better than now. Alex -- 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-developers
Re: [cmake-developers] Unit testing CMake modules
Hello Wouter,
testing CMake code is indeed very important. This is why kitware does it as
well. Did you check the CMake code testing infrastructure in "Tests/RunCMake"
in the sources? It is a very flexible concept which makes adding tests easy
enough for everyone contribute (IMO). At the beginning it might be a bit
confusing how expected results etc. are handled, but once you understand how it
works it's really nice.
Another (maybe the main) advantage: you have tons of examples and the RunCMake
infrastructure is maintained so you don't have to it all on your own.
best regards,
Michael
> -Ursprüngliche Nachricht-
> Von: cmake-developers [mailto:cmake-developers-boun...@cmake.org] Im
> Auftrag von Wouter Klouwen
> Gesendet: Dienstag, 29. Mai 2018 18:36
> An: CMake Developers
> Betreff: [cmake-developers] Unit testing CMake modules
>
> Hi all,
>
> We have a rather large amount of CMake code (4k+ lines) in various
> modules/functions. They contain the common logic for many of our projects.
> This makes it quite an important base for everything our team does.
>
> Rather shamefully at present these modules are rather poorly tested. I'd like
> to improve this, but the current way of testing CMake code is typically to run
> a trimmed project, and to verify whether certain invocations produce a
> certain output or file hierarchy.
> This involves a bit of infrastructure and can be a bit cumbersome maintain, to
> diagnose when tests fail, and it requires a separate run of the tests.
> The overall cumbersomeness of the setup in turn discourages in our team,
> including myself, from adding tests.
>
> I'd like a more integrated approach that makes running at least some basic
> tests part of the build progress, and a more direct way of reporting failures.
>
> In other programming environments, testing often involves some kind of
> mocking environment, and CMake helpfully allows the overriding of CMake
> built in functions, though this is typically discouraged.
>
> In my ideal world it would be possible to save the state of the current
> function set up, then call a function with a certain given number of
> parameters, and expect a certain sequence of events, such as functions to
> be called, environment variables to be set, etc.
> Something akin to CMakePushCheckState, except for built in functions.
>
> Then a module could provide for some functions that would set up
> expectations and verify them, within a run of cmake, or possibly some other
> commands could be added, to give some syntactic glossy coat to it.
>
> As it wouldn't actually trigger any of the expensive generating functions, it
> would be lightweight, quick to run and give pretty direct errors in terms of
> failed expectations, reducing debug time.
>
> If it was done with CMake commands, I might imagine it to look something
> like:
>
> function(foobar)
># function to test, does something non trivial
>if ("FOO" IN_LIST ARGV)
> install(FILES foo DESTINATION foo_dir)
>else("BAR" IN_LIST ARGV)
> message(FATAL_ERROR "Some error")
>else("BAZ" IN_LIST ARGV)
> set(BAZ True PARENT_SCOPE)
>endif()
> endfunction()
>
> test(foobar)
>expect(WITH "FOO" CALL install FILES foo DESTINATION foo_dir)
>expect(WITH "BAR" CALL message FATAL_ERROR "Some error")
>expect(WITH "BAZ" ENVIRONMENT BAZ True)
> endtest(foobar)
>
> What do people think? Is this crazy? Is there a quicker way to get somewhere
> close? Should I put some effort into making this into an actual
> proposal/working code?
>
> Thanks in advance,
> W
>
>
> This transmission contains information that may be confidential and contain
> personal views which are not necessarily those of YouView TV Ltd. YouView
> TV Ltd (Co No:7308805) is a limited liability company registered in England
> and
> Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower
> Thames Street, London, EC3R 6YT. For details see our web site at
> http://www.youview.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-developers
--
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/
Re: [cmake-developers] Unit testing CMake modules
A little while ago I wrote a framework to do just that:
https://github.com/polysquare/cmake-unit
I haven't maintained it in a few years, but it works exactly the way
you would expect it to (the syntax is a bit different though).
On Wed, May 30, 2018 at 12:36 AM, Wouter Klouwen
wrote:
> Hi all,
>
> We have a rather large amount of CMake code (4k+ lines) in various
> modules/functions. They contain the common logic for many of our
> projects. This makes it quite an important base for everything our team
> does.
>
> Rather shamefully at present these modules are rather poorly tested. I'd
> like to improve this, but the current way of testing CMake code
> is typically to run a trimmed project, and to verify whether certain
> invocations produce a certain output or file hierarchy.
> This involves a bit of infrastructure and can be a bit cumbersome
> maintain, to diagnose when tests fail, and it requires a separate run of
> the tests.
> The overall cumbersomeness of the setup in turn discourages in our team,
> including myself, from adding tests.
>
> I'd like a more integrated approach that makes running at least some
> basic tests part of the build progress, and a more direct way of
> reporting failures.
>
> In other programming environments, testing often involves some kind of
> mocking environment, and CMake helpfully allows the overriding of CMake
> built in functions, though this is typically discouraged.
>
> In my ideal world it would be possible to save the state of the current
> function set up, then call a function with a certain given number of
> parameters, and expect a certain sequence of events, such as functions
> to be called, environment variables to be set, etc.
> Something akin to CMakePushCheckState, except for built in functions.
>
> Then a module could provide for some functions that would set up
> expectations and verify them, within a run of cmake, or possibly some
> other commands could be added, to give some syntactic glossy coat to it.
>
> As it wouldn't actually trigger any of the expensive generating
> functions, it would be lightweight, quick to run and give pretty direct
> errors in terms of failed expectations, reducing debug time.
>
> If it was done with CMake commands, I might imagine it to look something
> like:
>
> function(foobar)
># function to test, does something non trivial
>if ("FOO" IN_LIST ARGV)
> install(FILES foo DESTINATION foo_dir)
>else("BAR" IN_LIST ARGV)
> message(FATAL_ERROR "Some error")
>else("BAZ" IN_LIST ARGV)
> set(BAZ True PARENT_SCOPE)
>endif()
> endfunction()
>
> test(foobar)
>expect(WITH "FOO" CALL install FILES foo DESTINATION foo_dir)
>expect(WITH "BAR" CALL message FATAL_ERROR "Some error")
>expect(WITH "BAZ" ENVIRONMENT BAZ True)
> endtest(foobar)
>
> What do people think? Is this crazy? Is there a quicker way to get
> somewhere close? Should I put some effort into making this into an
> actual proposal/working code?
>
> Thanks in advance,
> W
>
>
> This transmission contains information that may be confidential and contain
> personal views which are not necessarily those of YouView TV Ltd. YouView TV
> Ltd (Co No:7308805) is a limited liability company registered in England and
> Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower
> Thames Street, London, EC3R 6YT. For details see our web site at
> http://www.youview.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-developers
--
Sam Spilsbury
pgp.mit.edu: 0xb8a90fb599bae9c2
--
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-developers
Re: [cmake-developers] Proposed new CMake module FindITT.cmake
Hi Brad, I'm not a maintainer of SEAPI, so I may only propose a package config for it. And second thing - ITT library itself (not a part of SEAPI) is also used and distributed (ex. w/ Intel's VTune app.) -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Tuesday, May 29, 2018 6:12 PM To: Gurulev, Dmitry ; cmake-developers@cmake.org Subject: Re: [cmake-developers] Proposed new CMake module FindITT.cmake On 05/29/2018 10:30 AM, Gurulev, Dmitry wrote: > Although IntelSEAPI (which contains ITT sources) is a CMake based > library, ITT itself might be used as standalone binary library, so > finding module still makes sense If the upstream is CMake-friendly it should provide a CMake Package Configuration File with its SDK along with the headers and libraries. See documentation here: https://cmake.org/cmake/help/v3.11/manual/cmake-packages.7.html That will allow `find_package` to work without any find module and without guessing which headers and libraries match. Thanks, -Brad Joint Stock Company Intel A/O Registered legal address: Krylatsky Hills Business Park, 17 Krylatskaya Str., Bldg 4, Moscow 121614, Russian Federation This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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-developers
Re: [cmake-developers] Proposed new CMake module FindITT.cmake
ср, 30 мая 2018 г. в 8:38, Gurulev, Dmitry : > Hi Brad, > I'm not a maintainer of SEAPI, so I may only propose a package config for it. And second thing - ITT library itself (not a part of SEAPI) is also used and distributed (ex. w/ Intel's VTune app.) You can propose PR with CMake Package Configuration for SEAPI project on GitHub. If they found it reasonable, they will merge it. -- Best Regards, Sergei Nikulov -- 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-developers
Re: [cmake-developers] Proposed new CMake module FindITT.cmake
Yes, of course, I can. And I'm going to do that, I've already written. My question is - what about stand-alone ITT? -Original Message- From: Sergei Nikulov [mailto:sergey.niku...@gmail.com] Sent: Wednesday, May 30, 2018 8:52 AM To: Gurulev, Dmitry Cc: brad.k...@kitware.com; cmake-developers@cmake.org Subject: Re: [cmake-developers] Proposed new CMake module FindITT.cmake ср, 30 мая 2018 г. в 8:38, Gurulev, Dmitry : > Hi Brad, > I'm not a maintainer of SEAPI, so I may only propose a package config > for it. And second thing - ITT library itself (not a part of SEAPI) is also used and distributed (ex. w/ Intel's VTune app.) You can propose PR with CMake Package Configuration for SEAPI project on GitHub. If they found it reasonable, they will merge it. -- Best Regards, Sergei Nikulov Joint Stock Company Intel A/O Registered legal address: Krylatsky Hills Business Park, 17 Krylatskaya Str., Bldg 4, Moscow 121614, Russian Federation This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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-developers
