Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#207 CC, xlC file bids are case-insensitive

open
Curt Arnold
cpptasks (103)
5
2007-05-13
2007-05-13
David Haney
No

This issue was originally raised in Bug 1715475:

Based on some experiments, it looks like the extension comparison is case-insensitive (for all platforms), however at least some of the compilers I tested were case-sensitive in their handling of extensions (for example, the Forte compiler will accept a .cpp extension, but will reject a .CPP extension). Should CC-tasks file matching be case-sensitive or case-insensitive? Or should it be determined by the compiler (Windows compilers will probably be case-insensitive, while some Unix compilers will be case-sensitive).

Initial response from carnold:

Looks like a debatable decision down in compiler/AbstractProcessor. Definitely needs to be case-insensitive for the Windows compilers and gcc-like compilers on Windows. Is there a scenario you have where there is, for example, a compiler that handles ".C" and a different compiler that handles ".c" and the current behavior depends on the order of the bids? If there was a file that really wanted ".C" files, it could double its bid which would give it prescendence over a compiler that was just matching ".c". I'd be reluctant to change it until I knew of a harm.

Discussion

  • David Haney
    David Haney
    2007-05-13

    Logged In: YES
    user_id=1140024
    Originator: YES

    I recall running into an issue with HP where I was unable to use aCC in order to compile some C files, but the native cc compiler worked okay. In that case I would expect .C files to go to the aCC compiler instance, and .c files to go to the cc compiler. As long as the comparison is case-insensitive, it seems like the files would go to one or the other regardless of the bid priority (If I double the bid for .c in one of the compilers, that double-bid will apply to .C files as well).

    Instead of making the decision in the AbstractProcessor, what about making that method abstract, and requiring the downstream compiler/linker implementions define whether they perform their bids in a case-sensitive or insensitive manner. For example, all of the Unix compilers could provide implementations that assume case-sensitive, and be explicit which cases they support, while the Windows compilers could provide implementations that assume case-insensitive. The only one that seems hairy would be gcc, which may require different behavior depending on the OS, but that could be resolved for that compiler by checking the platform that we're on.

    I don't have a test case for this scenario at the moment, so I can't verify if this is still an issue, or if there was just a problem with the library I was attempting to compile at the time. This probably isn't a high-priority issue.