Yep, good point.

%lld is probably fine, but the pedantically correct thing is to use the PRId64 macro from <stdint.h> or <cstdint>. https://en.cppreference.com/w/cpp/types/integer

In DebugPrintEvents %7ld is used to print a pair of int64_t values. When compiling with Visual Studio that leads to printf mismatch warnings because on Windows (32-bit or 64-bit) long is a 32-bit value.

I believe that %7lld is a portable 64-bit format value. It definitely works for 32-bit and 64-bit Windows processes. This is the updated line of code that I used to fix the warnings:

    printf("%4zi: t=%i t1=%7lld t2=%7lld par=%4i ch=%4zi det=%s\n", i, (int) event.type, event.ts, event.ts+event.dur, event.parent.idx, event.children.size(), std::string(names[event.detailIndex].substr(0,130)).c_str());

ClangBuildAnalyzer pulls in Windows.h at several points, leading to these compilation errors:

src\main.cpp(175): error C2589: '(': illegal token on right side of '::'
src\external\flat_hash_map\flat_hash_map.hpp(1282): error C2589: '(': illegal token on right side of '::'

It looks like you've avoided this in the Visual Studio project by adding a global NOMINMAX define.

This should be done for the CMake build as well. I fixed it locally by adding this to CMakeLists:

target_compile_definitions(ClangBuildAnalyzer PRIVATE "NOMINMAX")

Interested in this as well.

@contre anything I could do to help move this along?

ClangBuildAnalysis is a great tool and it has really helped me improve the build time of a large project I am working on.

My project is so large that the code crashes when loading the json files. I believe it is running out of memory while parsing the json dom. my project has 83GB of json files. I have run ClangBuildAnalyzer on all the files and I can analyze all of them if I do it in two groups, with the 51 largest json files in one group and the other 241 files in the other group.

While debugging, I changed the max tasks to 1 in main.cpp, hoping that parsing 1 json at a time would reduce the memory footprint. It may have gotten farther, but ClangBuildAnalyzer still crashed.

I tried using gdb to see the crash, but the app is killed due to out of memory, instead of core dumping, so gdb didn't give me any useful information.

I wondered if there was a memory leak or other bug in the json parsing. I manually copied the latest release of simdjson (0.9.4) into ClangBuildAnalyzer and rebuilt. I still got the same crashes.

I am currently using clang-11. I had more luck with ClangBuildAnalyzer on this project in the past and may have been using clang-10. I wonder if clang-10 writes fewer events? I do not see any warnings about unknown events while running ClangBuildAnalyzer with clang-11.

Could ClangBuildAnalyzer support a batch mode to support large projects? For example, I could run ClangBuildAnalyzer -all <subdirN> on the N subdirs of my build. Then, I would run ClangBuildAnalyzer --analyze with N file names instead of 1. ClangBuildAnalyzer would then read all N binary event files and concatenate all the data together before producing the statistics over the combined set of all events.

I have studied the LoadBuildEvents() method and believe it could be possible to have it append new files to the current event and names lists, but haven't had time to do it yet, especially making the event to name index is updated correctly.

This one was addressed in a different way by #62, and now would be conflicting.

The rt library is unconditionally added as requirement in file CMakeLists.txt:

target_link_libraries(ClangBuildAnalyzer -lrt -lpthread)

This library is not present on macOS, and hence the build fails.

When I remove the -lrt entry, building succeeds.

The line above should be changed like:

if (APPLE)
  target_link_libraries(ClangBuildAnalyzer -lpthread)
else()
  target_link_libraries(ClangBuildAnalyzer -lrt -lpthread)
endif()

I can make a PR if requested.

Ok, blindly merged #62 (GitHub Actions are seemingly failing everywhere with internal errors today). 🤞

This is a duplicate of #55, but rather than hardcoding rules depending on the OS, I'm using CMake to discover -lrt or -lpthread.

Fixes #57

Recently, when trying to use ClangBuildAnalyzer to analyze a firefox build, I got the following error and assertion failure on ClangBuildAnalyzer --stop:

ERROR: Failed to open directory (obj-x86_64-pc-linux-gnu-trace/dist/bin/chrome/en-US/locale/en-US/mozapps/downloads/settingsChange.dtd): No such file or directory.
ClangBuildAnalyzer: ../src/external/cute_files.h:427: int cf_dir_open(cf_dir_t*, const char*): Assertion `0' failed.

obj-x86_64-pc-linux-gnu-trace/dist/bin/chrome/en-US/locale/en-US/mozapps/downloads/settingsChange.dtd exists, but is a symbolic link to a file, not a directory:

[simon@sigibln fuzzy]$ stat obj-x86_64-pc-linux-gnu-trace/dist/bin/chrome/en-US/locale/en-US/mozapps/downloads/settingsChange.dtd
  File: obj-x86_64-pc-linux-gnu-trace/dist/bin/chrome/en-US/locale/en-US/mozapps/downloads/settingsChange.dtd -> /home/simon/work/fuzzy/toolkit/locales/en-US/chrome/mozapps/downloads/settingsChange.dtd
  Size: 88              Blocks: 8          IO Block: 4096   symbolic link
Device: fd02h/64770d    Inode: 34560445    Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/   simon)   Gid: ( 1000/   simon)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2020-10-21 18:42:33.948517287 +0200
Modify: 2020-10-14 18:48:03.012265746 +0200
Change: 2020-10-14 18:48:03.012265746 +0200
 Birth: 2020-10-14 18:48:03.012265746 +0200
[simon@sigibln fuzzy]$ stat /home/simon/work/fuzzy/toolkit/locales/en-US/chrome/mozapps/downloads/settingsChange.dtd
  File: /home/simon/work/fuzzy/toolkit/locales/en-US/chrome/mozapps/downloads/settingsChange.dtd
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: fd02h/64770d    Inode: 49026953    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/   simon)   Gid: ( 1000/   simon)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2020-10-22 09:43:44.048022446 +0200
Modify: 2020-10-22 09:43:34.870015064 +0200
Change: 2020-10-22 09:43:34.870015064 +0200
 Birth: 2020-10-22 09:43:29.366010639 +0200

@aras-p I reverted that change as you requested, can this be merged now?

Yes, #62 would fix this.

There's already that fixes this problem: https://github.com/aras-p/ClangBuildAnalyzer/pull/62

@aras-p may I kindly ask you to take a look, please?

The rt library is unconditionally added as requirement in file CMakeLists.txt:

target_link_libraries(ClangBuildAnalyzer -lrt -lpthread)

This library is not present on macOS, and hence the build fails.

When I remove the -lrt entry, building succeeds.

The line above should be changed like:

if (APPLE)
  target_link_libraries(ClangBuildAnalyzer -lpthread)
else()
  target_link_libraries(ClangBuildAnalyzer -lrt -lpthread)
endif()

I can make a PR if requested.

mtime.time is of type FILETIME when compiling under MinGW x64 using MSYS2. The presence of -lrt causes a linker error as well, removing it fixes the issue.

NuGet release?