mstorsjo wrote: > To me, the general theory is that Cygwin is more UNIXy than Windowsy, so I > based this off of actually the Hurd.h/cpp (as it had pretty limited amounts > of special cases).
Sounds like a reasonable guess. In practice it's probably somewhere inbetween, and which side ends up dominating is hard to guess beforehand, but considering it mostly UNIXy is probably reasonable, and sticking close to the existing `Generic_GCC` case makes it much easier to review as a gradual change, rather than a full from-scratch implementation. > It looks to me like the #74933 PR followed the from-scratch ToolChain idea, > and that probably accounts for why it was much more code. I can look at that > more closely and see if there's anything I'm missing. Thanks, that's appeciated, although probably not strictly needed at this point. And if there are other valuable nuggets in there, we can probably add them as incremental changes on top here. > I believe cygwin target testing is very lacking/non-existent. Yes, definitely. And your and @mati865's effort here is very very much appreciated! > I don't have experience with llvm's test suite though, but if it's just a > matter of adding additional cases to existing tests or maybe copying some > existing tests I might be OK figuring it out. Yeah it's usually not that hard to figure out. A couple general pointers: - You can run all tests with `ninja check-clang` or so, but if working on one single test, it's much faster to run e.g. `bin/llvm-lit -a ../clang/test/Driver/mytest.c` to only run one single test, or `bin/llvm-lit -sv ../clang/test/Driver` to run one subdirectory - The general philosophy of tests within Clang and LLVM is to test the minimal scope at each level. Initially, it may feel more intuitive to test the driver by e.g. actually trying to compile something, but such a test only works if you actually have the full environment available. But in Clang/LLVM, as many tests as possible are desired to be runnable on any host, without any dependencies. So e.g. a Clang codegen test takes a minimal selfcontained `.c` input and produces LLVM IR (which can be done on any host), a Clang driver test mostly runs with `-###` to check which `-cc1` command flags would be prouduced for that. If necessary, it may set up a mock sysroot and try to make Clang use that; some such tests rely on symlinking (and such tests may only be usable on Unix or other systems where symlinks generally are usable) - some of the mingw driver tests do that. - As this is a new driver, I guess it'd be fine to just start out with some very minimal test, trying to compile, `clang -### -c ...` and link `clang -### foo.o -o foo.exe` and inspect some minimal detail in them. - As a general rule, in Clang/LLVM, every functional change must be accompanied by a test change/update to cover what is being changed. (As an exception, if the test relies on tricky environmental factors it may be ok to go without a testcase, but if possible to mock the environment, that's preferred.) https://github.com/llvm/llvm-project/pull/135691 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
