should be done at the target level

https://github.com/CommE2E/comm/blob/e7b0a922126f415741569eb78edbd7a65f8826b0/native/cpp/CommonCpp/grpc/CMakeLists.txt#L49-L53

I don't think tests are all that worthwhile, as running the tests can be done from the build directory. But I would be happy to be proven wrong.

I don't think tests are all that worthwhile

I meant to say, all that worthwhile to declare install output paths, as we will likely be running the tests from the build directory.

should be done at the target level

https://github.com/CommE2E/comm/blob/e7b0a922126f415741569eb78edbd7a65f8826b0/native/cpp/CommonCpp/grpc/CMakeLists.txt#L49-L53

I don't think tests are all that worthwhile, as running the tests can be done from the build directory. But I would be happy to be proven wrong.

Yes, we are running the tests app from the build directory (in D5461).

What's the benefits to use of install TARGETS... here instead of setting a simple CMAKE_RUNTIME_OUTPUT_DIRECTORY ?

For me, it makes sense for the blob as we are exporting headers for the client and etc. In this case, just build and run the tests and we can go with the simple solution.

Can we add a quick comment explaining what the CMP0003 policy is? Just a sentence and a link to https://cmake.org/cmake/help/latest/policy/CMP0003.html should suffice.

I think the simple one would be enough. I've added it.

What's the benefits to use of install TARGETS... here instead of setting a simple CMAKE_RUNTIME_OUTPUT_DIRECTORY ?

If you do add_subdirectory and target this file, then you're not going to clobber the global definition of what should go where.

It's considered best practice to avoid the old global behavior options of cmake, and instead encapsulate behavior on a per-target basis.

For me, it makes sense for the blob as we are exporting headers for the client and etc. In this case, just build and run the tests and we can go with the simple solution.

I'm pretty sure if you remove the line, the default is that it will build runTests in ${CMAKE_CURRENT_BINARY_DIR}/bin/ anyway. I would just like to avoid footguns, as the GLOB RECURSIVE has been bitting us as well lately.

What's the benefits to use of install TARGETS... here instead of setting a simple CMAKE_RUNTIME_OUTPUT_DIRECTORY ?

If you do add_subdirectory and target this file, then you're not going to clobber the global definition of what should go where.

It's considered best practice to avoid the old global behavior options of cmake, and instead encapsulate behavior on a per-target basis.

For me, it makes sense for the blob as we are exporting headers for the client and etc. In this case, just build and run the tests and we can go with the simple solution.

I'm pretty sure if you remove the line, the default is that it will build runTests in ${CMAKE_CURRENT_BINARY_DIR}/bin/ anyway. I would just like to avoid footguns, as the GLOB RECURSIVE has been bitting us as well lately.

Thanks for the clarification @jon!
Despite the CMake documentation saying that the default dir for the RUNTIME is bin when I remove the CMAKE_RUNTIME_OUTPUT_DIRECTORY and add:

install(TARGETS runTests
  RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
  ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
)

the binary is in the build directory as well if I use just install(TARGETS runTests RUNTIME DESTINATION bin) which must use build/bin directory. But it's not and puts the binary into the build directory.

I don't mind removing the CMAKE_RUNTIME_OUTPUT_DIRECTORY and just using the build for the binary. I'll adjust the commands for the build directory in D5461 as well if we will go with it and this will be accepted.