addIncludeDir() seems to use -isystem to add include directories to the zig cc include search path. This has unfortunate consequences if the C file you're trying to build includes a header that uses a name that happens to conflict with a system header. In my particular case, I had a header that was called error.h, which was included from a .c file in a subdirectory without a relative path. This worked fine using my normal CMake build system - I just used target_include_directories to add the parent directory to the include search path and went on with my life. But when messing around with zig build, I started getting implicit definition warnings and it took me a while to figure out what was going on - I had used addIncludeDir and zig cc was finding a globally-installed error.h before my local one.
I think that I was unwise to take this approach with my C code in the first place, and that I'm probably better off using a relative path like #include "../error.h", but it does seem like a strange choice to default to -isystem when adding an include directory, with no apparent setting to use -iquote or -I except through modifying the cflags by hand. With all the C code that's out there, I can't imagine that I'm the only foolish one.
-I command line argument, (both variants -Ifoo and -I foo)addIncludeDir uses -I.addSystemIncludeDir which uses -isystemdone in 3af2202ea4a5950541ee369a005f8e4484d544ab and 9bc4f8ea77df395b9f2407ddfa4734bb4a1c4139
Most helpful comment
done in 3af2202ea4a5950541ee369a005f8e4484d544ab and 9bc4f8ea77df395b9f2407ddfa4734bb4a1c4139