I’m writing a lit test that needs to temporarily make a subdirectory.
I tried:
// RUN: mkdir %t/subdir
But on Windows, it’s hard to bypass the built-in mkdir to use a Posix-style one from Git or GnuWin. The built-in mkdir believes the /subdir is an unrecognized command flag. I figure I cannot just use a backslash because that would fail on Posix systems. (The test should run on all platforms.)
The lit documentation mentioned a %{pathsep} macro, so I tried that. After several minutes of confusing results, I discovered this is not for the path component separator, but for the separators used between paths in the PATH environment variable. On Windows, that’s ‘;’, which doesn’t help.
Suggestions?
Thanks,
Adrian McCarthy
Why does this test need a separate directory?
The test is to confirm that LLDB can locate a PDB symbol file that corresponds to the target executable. In the executable, the linker writes the location where it generated the PDB file. I need that path to be a different directory than the directory for the executable itself because the fallback search includes the directory of the executable.
there are some existing tests that seem to do this, for instance:
llvm/test/tools/llvm-ar/lto-kind-from-triple.test
Are these not running on Windows?
Yeah, the llvm-ar tests are working on Windows. But I’m getting different results when I try to use the same commands in an LLDB lit test. Maybe there’s something messed up in LLDB’s local lit config?
If I have mkdir %t/subdir in my lit test, I get either file-not-found or a complaint about “unrecognized option /subdir.”
The one-and-only mkdir on my PATH is “C:\Program Files\Git\usr\bin\mkdir.exe”. If I run that explicitly, bypassing the one build into the Windows CMD prompt, I can use --help, --parents, and --version (among others). But if I issue those commands from the lit test, I get reports of “unsupported option: --parents” and subdirectories named --help and --version. That tells me lit isn’t running the same command, though the “unsupported option” is not an error message I’d expect from CMD’s mkdir.
The GnuWin tools have been removed from my machine for a while now. which and where report only the Git version.
'Tis a puzzle.
Looks like 989c9e75a6fd1ef6eed9777fcd95b0f40b93f40c added a
lit-internal version of mkdir. Not sure if/how that is/isn't exposed
to lldb's test suites.
Thanks for your help. I had multiple issues confusing the situation, including some correct-but-surprising parsing by lit. But it must have been mostly pilot area (though honestly I’m not exactly sure how to explain some of the results I had.) The clue that lit has an internal implementation of mkdir was very useful in sorting it all out.