0

We have some npm builds that are being kicked off in a cmake package. This does not work well and the error messages being produced are completely unintelligible.

In order to mitigate this, I'm attempting to add a layer of processing to produce a helpful message to developers so that they can understand what they need to do (in this case, update some content inside the CMakeLists.txt itself).

Here is as far as I've gotten. I have created my script "scripts/check-files.sh", and I can definitely successfully trigger its execution via

add_custom_target(check_files ALL
  COMMAND ${CMAKE_COMMAND} -E echo "check_files: Checking if your files are properly listed for the file lists in CMakeLists.txt:"
  COMMAND "${CMAKE_CURRENT_LIST_DIR}/scripts/check-files.sh")

This is producing

make[2]: *** [CMakeFiles/check_files] Error 1
make[1]: *** [CMakeFiles/check_files.dir/all] Error 2

when check-files.sh fails and produces a nonzero return code, and this doesn't happen when it succeeds. Because i'm able to control cmake's behavior by changing how check-files.sh behaves, I know that it is properly executing it. Why do I have to talk about this? Well...

The problem: I'm not able to coerce cmake to show me the output check_files: Checking if your files are properly listed for the file lists in CMakeLists.txt: nor the output of the check-files.sh execution. Note that I'm not using COMMENT. Apparently one can never even count on that working. But... COMMAND ${CMAKE_COMMAND} -E echo does not appear to do anything either.

As I'm having so much trouble even to make the output of my helper checker script display, I can think of one thing that does display which is the name:

add_custom_target("check_files_PLEASE_CHECK_YOUR_FILE_LIST_IN_CMakeLists.txt" ALL

yielding

make[2]: *** [CMakeFiles/check_files_PLEASE_CHECK_YOUR_FILE_LIST_IN_CMakeLists.txt] Error 1
make[1]: *** [CMakeFiles/check_files_PLEASE_CHECK_YOUR_FILE_LIST_IN_CMakeLists.txt.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2

This is a great distance from being ideal but is enough of a visual signature to clue someone in, it may have to do.

Steven Lu
  • 41,389
  • 58
  • 210
  • 364
  • You might consider using other build automation tools (e.g. [ninja](https://ninja-build.org/)...) where such tasks are a lot simpler – Basile Starynkevitch Aug 07 '20 at 06:32
  • @BasileStarynkevitch No doubt, no doubt. Not possible with this project which relies on `catkin` which is probably even worse than vanilla `cmake`. How that's even possible is astounding. I'm at a loss for words at how much of a pure abject failure that cmake truly is as a tool. A tool is supposed to help you get your work done quicker! It beggars belief. – Steven Lu Aug 07 '20 at 06:37
  • Yes, I also profoundly dislike `cmake`, but I admit not being expert with it – Basile Starynkevitch Aug 07 '20 at 06:39

1 Answers1

0

Try using COMMAND /bin/sh yourscript.sh, or even better - first search for proper interpreter with find_program and then use the result to run the script.

arrowd
  • 33,231
  • 8
  • 79
  • 110
  • It would appear that COMMAND probably is treated like running a compile command. definitely hidden without using something like [this](https://stackoverflow.com/questions/12823799/cmake-how-to-show-the-compilers-stdout/12841234) to show the massively verbose output (not what i want). – Steven Lu Aug 07 '20 at 10:36
  • IIRC, you **should** see the commands output. Maybe you're running it in the wrong `WORKING_DIRECTORY`? – arrowd Aug 07 '20 at 10:42
  • Nope it does complain of not being able to find the script if i fiddle with WORKING_DIRECTORY and get it wrong. Explicitly specifying the directory seems much cleaner as it seems like I have to use a `./check-files.sh` path with it, which looks more confusing – Steven Lu Aug 07 '20 at 13:22