3 ms·

Interestingly, the blog post doesn't mention the actual problem that's the source of the MSVC behaviour: not all filesystems are case-sensitive. So if you care

Interestingly, the blog post doesn't mention the actual problem that's the source of the MSVC behaviour: not all filesystems are case-sensitive. So if you care about your project being able to be checked out on Windows, please refrain from using .C extension for C++ files. I've seen a toy language repo that used "something.s" for the test source file and "something.S" for the part of the language runtime (or something like this, don't quite remember), and checking it out on Windows was great fun: git declares that the working directory at the same time is both dirty and has no changes in files.

DSMan195276 6y ago
That's actually an interesting one - for gcc at least `.S` indicates an assembly file that requires preprocessing via `cpp`, and `.s` does not. You could definitely wire it up such that a different extension indicates preprocessing (and there might be some others already), but the typical convention would run into this problem. Of course, you're not supposed to check in the preprocessed source, but you'd likely run into the problem at build time when it tries to create the preprocessed file with the same filename as the original, so it doesn't really solve the problem.
- cesarb 6y ago
  > but you'd likely run into the problem at build time when it tries to create the preprocessed file with the same filename as the original Only if you use -save-temps, which is rarely used (it's there mostly for when you want to debug the preprocessed code). Otherwise, in the common case where you are going from the .S to the .o, the intermediate .s is saved somewhere in /tmp (without -pipe) or exists only in memory (with -pipe).
  - DSMan195276 6y ago
    Yeah that's a good point, I didn't really think about it too hard but usually you just go straight from the `.S` to the `.o` and more-or-less skip the intermediate.
kalleboo 6y ago
If you care about Windows you also need to watch out for filenames like aux, con, prn, etc
- Joker_vD 6y ago
  Yep, checking out NetBSD or Minix 3 on Windows runs into this exact problem with the directory "external/mit/xorg/lib/xcb-util/aux". Thankfully, no NetBSD or Minix users need X anyway, right? :)

DSMan195276 6y ago

That's actually an interesting one - for gcc at least `.S` indicates an assembly file that requires preprocessing via `cpp`, and `.s` does not. You could definitely wire it up such that a different extension indicates preprocessing (and there might be some others already), but the typical convention would run into this problem. Of course, you're not supposed to check in the preprocessed source, but you'd likely run into the problem at build time when it tries to create the preprocessed file with the same filename as the original, so it doesn't really solve the problem.

cesarb 6y ago
> but you'd likely run into the problem at build time when it tries to create the preprocessed file with the same filename as the original Only if you use -save-temps, which is rarely used (it's there mostly for when you want to debug the preprocessed code). Otherwise, in the common case where you are going from the .S to the .o, the intermediate .s is saved somewhere in /tmp (without -pipe) or exists only in memory (with -pipe).
- DSMan195276 6y ago
  Yeah that's a good point, I didn't really think about it too hard but usually you just go straight from the `.S` to the `.o` and more-or-less skip the intermediate.

kalleboo 6y ago

If you care about Windows you also need to watch out for filenames like aux, con, prn, etc

Joker_vD 6y ago
Yep, checking out NetBSD or Minix 3 on Windows runs into this exact problem with the directory "external/mit/xorg/lib/xcb-util/aux". Thankfully, no NetBSD or Minix users need X anyway, right? :)