[Night_Thastus]

Does that just profile cmake's time to configure and generate, or the underlying compile of each file as well? Configuration and generation are only seconds when done from scratch - the build is more like 20 minutes.

Just trying to add that argument with 3.26.5 on Rocky Linux 9, I get 'Unknown argument --profiling-format=google-trace'.

Not sure why, as cmake --help clearly states it should be there...

  --profiling-format=<fmt>     = Output data for profiling CMake scripts.
                                 Supported formats: google-trace
  --profiling-output=<file>    = Select an output path for the profiling data
                                 enabled through --profiling-format.

[tom_]

You might need to specify --profiling-output= as well. I get an error fdrom cmake 3.31 if only the format is provided: CMake Error: --profiling-format specified but no --profiling-output!

Anyway, it looks like it only profiles the configure/generate steps. Not much use on Linux, but on Windows/macOS, perhaps. Due to lack of any standard package manager, it's a good idea to build every dependency from source on those OSs, and the time can mounts up.

My project is not that large, but it takes 1 minute to configure from scratch on Windows, and 10 minutes (!) on macOS.

[Night_Thastus]

I specified both. In any case, yeah, cmake time isn't useful in my case.

Bizarre that you see 10 minutes on MacOS. Something's definitely busted there. It's not even that bad for me on Windows, and that's saying something.

[tom_]

For the record: the cmake profiling data did help a bit. On macOS it seems that the configure stage does 200+ try_compiles, largely due to SDL2, and each one somehow takes ~2.3 seconds. So that's 460 seconds right there. And regarding the total time, it's actually more like 480 seconds. (I must have misremembered! Or perhaps my laptop is measurably faster when its integrated GPU isn't driving 2 external displays.)

On Windows: 50 try_compiles, about half and half SDL2 and libuv, and each one takes ~1 second.

I don't think either of these try_compile turnaround times is acceptable (what is it doing?! I bet it's like 50 ms on Linux) but the total figure does now feel a bit less mysterious.

[wakawaka28]

You might also like my suggestions in this comment: https://news.ycombinator.com/item?id=44931551

[wakawaka28]

That does just do CMake time. Sorry if my comment was confusing. I forgot that I used a wrapper or something myself to collect the compile times. Anyway, my point is, you aren't the first person to have this issue. I've definitely profiled compile times before and viewed a flame graph with some gadget made by Google. The easiest way you to do it may depend on your compiler and build system. You could attack the problem from Ninja or Make, or by substituting your compiler binary for a wrapper script.

I also want to point out that if you want Ninja, it is a very minimal binary to build with no dependencies that wouldn't already be installed.

This is one of the simpler ways to find out what's going on: https://alangrow.com/blog/profiling-every-command-in-a-makef... Instead of replacing the shell you can also replace CC or CXX variables (if I recall properly) either in CMake or the Makefile to replace your compiler with a wrapper script that logs stuff.

More generalized Makefile profiling: https://github.com/konturio/make-profiler

Profiling with Clang: https://aras-p.info/blog/2019/01/16/time-trace-timeline-flam... (Maybe what I used last time...)

I am pretty sure you can get shiny outputs from a free profiling tool, but I think you can search for that yourself. It should be easy to find something. Good luck!