The case insensitive #include statement horror...

Discussion in 'C++' started by Stephan Kuhagen, Nov 29, 2006.

  1. Hello

    Please forgive me, if this is the wrong NG, since this is a compiler
    specific C++-Question:

    I'm managing a huge build system for multiple platforms (Win*, Linux,
    MacOSX). Most of our programmers work on Windows and seem to be unable to
    learn the difference between upper and lower case characters in #include.
    So most time the thing works on Windows, but fails on the others. Although
    they get mails when a project fails, the errors either do not get fixed or
    they re-appear after every change... This is _really annoying_ ! - Does
    anyone here know a switch or trick to make the Microsoft-Compilers (VC6 and
    up) case-sensitive in #include-statements and throw an error on wrong case?

    "Thanks for not shooting me"
    Regards
    Stephan Kuhagen
    Stephan Kuhagen, Nov 29, 2006
    #1
    1. Advertising

  2. Stephan Kuhagen

    Ondra Holub Guest

    Stephan Kuhagen napsal:
    > Hello
    >
    > Please forgive me, if this is the wrong NG, since this is a compiler
    > specific C++-Question:
    >
    > I'm managing a huge build system for multiple platforms (Win*, Linux,
    > MacOSX). Most of our programmers work on Windows and seem to be unable to
    > learn the difference between upper and lower case characters in #include.
    > So most time the thing works on Windows, but fails on the others. Although
    > they get mails when a project fails, the errors either do not get fixed or
    > they re-appear after every change... This is _really annoying_ ! - Does
    > anyone here know a switch or trick to make the Microsoft-Compilers (VC6 and
    > up) case-sensitive in #include-statements and throw an error on wrong case?
    >
    > "Thanks for not shooting me"
    > Regards
    > Stephan Kuhagen


    Hi. I was dealing with the same problem too. But it is not problem of
    compiler, it is problem of filesystem, because on FAT or NTFS are
    always files, which differ only in upper/lower case letters, treated as
    same files. You can try it with gcc on Windows, there is the same
    problem.
    Ondra Holub, Nov 29, 2006
    #2
    1. Advertising

  3. Ondra Holub wrote:

    > Hi. I was dealing with the same problem too. But it is not problem of
    > compiler, it is problem of filesystem, because on FAT or NTFS are
    > always files, which differ only in upper/lower case letters, treated as
    > same files. You can try it with gcc on Windows, there is the same
    > problem.


    Yes, I know. But since Windows is able to show the filenames in correct case
    in the Explorer or even with dir in the console, I thought (desperately
    hoped...) there may be a switch in the MS compilers or an obscure pragma to
    make them check the spelling...

    Regards
    Stephan
    Stephan Kuhagen, Nov 29, 2006
    #3
  4. Stephan Kuhagen

    Ondra Holub Guest

    Stephan Kuhagen napsal:
    > Ondra Holub wrote:
    >
    > > Hi. I was dealing with the same problem too. But it is not problem of
    > > compiler, it is problem of filesystem, because on FAT or NTFS are
    > > always files, which differ only in upper/lower case letters, treated as
    > > same files. You can try it with gcc on Windows, there is the same
    > > problem.

    >
    > Yes, I know. But since Windows is able to show the filenames in correct case
    > in the Explorer or even with dir in the console, I thought (desperately
    > hoped...) there may be a switch in the MS compilers or an obscure pragma to
    > make them check the spelling...
    >
    > Regards
    > Stephan


    I would have one (obscure) solution. I do not know, which versioning
    system are you using. Some of versioning systems allow run some script
    during checking-in new version of source. Such script may perform some
    checks or modifications of file being checked-in (adding change log,
    etc.). I think in ClearCase is possible to decline check-in by script.
    So you could write your own script, whcih checks all #includes for
    validity.

    As I wrote, it is obscure, but it should work and this script shouldn't
    be as complicated.
    Ondra Holub, Nov 29, 2006
    #4
  5. Stephan Kuhagen

    Ron Natalie Guest

    Stephan Kuhagen wrote:
    > Hello
    >
    > Please forgive me, if this is the wrong NG, since this is a compiler
    > specific C++-Question:


    How the stuff between the "" or <> is mapped to files is entirely
    implementation specific.

    While windows is lenient with case issues, UNIX typically is not.
    Best to get the case right.
    Ron Natalie, Nov 29, 2006
    #5
  6. Ondra Holub wrote:

    > I would have one (obscure) solution. I do not know, which versioning
    > system are you using. Some of versioning systems allow run some script
    > during checking-in new version of source. Such script may perform some
    > checks or modifications of file being checked-in (adding change log,
    > etc.). I think in ClearCase is possible to decline check-in by script.
    > So you could write your own script, whcih checks all #includes for
    > validity.
    >
    > As I wrote, it is obscure, but it should work and this script shouldn't
    > be as complicated.


    Hehe, thanks, but I already did that. I wrote a Python-package that is able
    to check several rules from our programming style guide. But this only
    produces one more place with an ignored error message in the build system.
    The only really good solution would be to make the code uncompilable on
    Windows and let the compiler throw an error... If they can't use their own
    code on their Windows-Machine they must fix it...

    Stepgan
    Stephan Kuhagen, Nov 29, 2006
    #6
  7. Stephan Kuhagen wrote:
    > Ondra Holub wrote:
    >
    >> Hi. I was dealing with the same problem too. But it is not problem of
    >> compiler, it is problem of filesystem, because on FAT or NTFS are
    >> always files, which differ only in upper/lower case letters, treated
    >> as same files. You can try it with gcc on Windows, there is the same
    >> problem.

    >
    > Yes, I know. But since Windows is able to show the filenames in
    > correct case in the Explorer or even with dir in the console, I
    > thought (desperately hoped...) there may be a switch in the MS
    > compilers or an obscure pragma to make them check the spelling...


    You might want to ask in 'microsoft.public.vc.language'... Next time
    please post all compiler-specific questions (and answers) to the right
    newsgroup.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Nov 29, 2006
    #7
  8. Stephan Kuhagen

    rossum Guest

    On Wed, 29 Nov 2006 14:54:03 +0100, Stephan Kuhagen
    <> wrote:

    >Hehe, thanks, but I already did that. I wrote a Python-package that is able
    >to check several rules from our programming style guide. But this only
    >produces one more place with an ignored error message in the build system.

    If code cannot compile without any errors or warnings, then it should
    not be released. Maybe a change to your local standards is needed?

    >The only really good solution would be to make the code uncompilable on
    >Windows and let the compiler throw an error... If they can't use their own
    >code on their Windows-Machine they must fix it...

    Can your Python package alter the text of the source files as they are
    scanned? If so just add "-Incorrect Case" to all invalid filenames so
    they won't compile:

    #include <FiLeNaMe.AbC>

    would become

    #include <FiLeNaMe.AbC-Incorrect Case>

    which will cause a "File not found" error at the very least

    rossum
    rossum, Nov 29, 2006
    #8
  9. rossum wrote:

    > If code cannot compile without any errors or warnings, then it should
    > not be released. Maybe a change to your local standards is needed?


    The standards are this way, its the (Windows-)programmers brains that are
    not that way...

    If the code has compiler errors, it is not released of course. Getting rid
    of all warnings is impossible, if you have several millions lines of code
    which must compile on 3 platforms with 7 different compilers (WinXP/2k VC6,
    VC7, VC8, Linux GCC 4.0/4.1, MacOSX gcc 4.0 on PPC and i86)...

    What I want to achieve, is to get the code faster into a good state, and
    since there is code to be released and code to be used only internal which
    can be released sometime in the future, when it is stable and good enough,
    this would make more code faster releasable.

    > #include <FiLeNaMe.AbC>
    >
    > would become
    >
    > #include <FiLeNaMe.AbC-Incorrect Case>
    >
    > which will cause a "File not found" error at the very least


    Yes, I tried this, but it has the disadvantage, that this is only a 20%
    solution: The Python code must not only look for the exact file in the same
    directory, but everywhere, where a compiler might search for includes
    (which would be really hard to do, because of include paths and such).

    I thought much about the problem, and the only solution seems to me, to make
    the Microsoft compilers fail on those include-statements.

    Regards
    Stephan
    Stephan Kuhagen, Nov 30, 2006
    #9
  10. Victor Bazarov wrote:

    > You might want to ask in 'microsoft.public.vc.language'... Next time
    > please post all compiler-specific questions (and answers) to the right
    > newsgroup.


    Thanks for the advice, I did not know these groups and had no Idea, where to
    ask. - So I posted in microsoft.public.vc.language and related now, but did
    not get an answer. Maybe the problem has no solution. - Although I can not
    really accept that...

    Thanks anyway
    Stephan
    Stephan Kuhagen, Nov 30, 2006
    #10
  11. Stephan Kuhagen wrote:

    > Victor Bazarov wrote:
    >
    > > You might want to ask in 'microsoft.public.vc.language'... Next time
    > > please post all compiler-specific questions (and answers) to the right
    > > newsgroup.

    >
    > Thanks for the advice, I did not know these groups and had no Idea, where to
    > ask. - So I posted in microsoft.public.vc.language and related now, but did
    > not get an answer. Maybe the problem has no solution. - Although I can not
    > really accept that...


    <ot>
    The underlying NTFS system is case sensitive. I don't know about POSIX
    compilers running on Windows (or even about POSIX support on current
    Windows platforms), but if you run a POSIX C++ compiler on Windows then
    it will have access to the case sensitive filenames (it is the Windows
    API which is case in-sensitive, not the file system).

    Maybe switching to a POSIX compiler or including one in your Windows
    build will get your developers to use the right case. If you're (very)
    lucky you may be able to run your Linux/Unix compiler directly under
    Windows.
    </ot>

    I can't help but think though that if the discipline is so poor that
    the developers are not able, or willing, to match case on the #includes
    then this is simply the most visible of a whole raft of issues that are
    in the code they produce.


    K
    =?iso-8859-1?q?Kirit_S=E6lensminde?=, Nov 30, 2006
    #11
  12. * Stephan Kuhagen:
    > rossum wrote:
    >
    >> If code cannot compile without any errors or warnings, then it should
    >> not be released. Maybe a change to your local standards is needed?

    >
    > The standards are this way, its the (Windows-)programmers brains that are
    > not that way...


    If the programmers can be required to use certain tools or drivers or
    whatever, then they can certainly be required to e.g. use all lowercase
    file names.


    > If the code has compiler errors, it is not released of course. Getting rid
    > of all warnings is impossible,


    No, it's a management decision: do we deliver quality or not? Since it
    seems that management is not interested in enforcing local standards, it
    seems they're squarely in the "or not" camp. Then yes it might be
    well-night impossible, futile and detrimental to one's career to strive
    for quality, but technically impossible it's certainly not.


    > if you have several millions lines of code
    > which must compile on 3 platforms with 7 different compilers (WinXP/2k VC6,
    > VC7, VC8, Linux GCC 4.0/4.1, MacOSX gcc 4.0 on PPC and i86)...


    Right, the VC6 compiler should be removed from the list. That leaves
    four compiler (versions) out of the seven. :)


    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Nov 30, 2006
    #12
  13. Alf P. Steinbach wrote:

    >> if you have several millions lines of code
    >> which must compile on 3 platforms with 7 different compilers (WinXP/2k
    >> VC6, VC7, VC8, Linux GCC 4.0/4.1, MacOSX gcc 4.0 on PPC and i86)...

    >
    > Right, the VC6 compiler should be removed from the list.


    True, since I often have the feeling, that VC6 is not a C++ compiler at
    all...

    > That leaves
    > four compiler (versions) out of the seven. :)


    Nope, the MacOSX compilers are patched by Apple, so they behave slightly
    different than gcc on Linux...

    Regards
    Stephan
    Stephan Kuhagen, Nov 30, 2006
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tee
    Replies:
    3
    Views:
    7,793
    Herfried K. Wagner [MVP]
    Jun 23, 2004
  2. Ariel Gimenez

    Horror

    Ariel Gimenez, Aug 7, 2004, in forum: ASP .Net
    Replies:
    4
    Views:
    663
    Ariel Gimenez
    Aug 7, 2004
  3. Rui Maciel
    Replies:
    67
    Views:
    2,092
    Christopher Layne
    Feb 16, 2007
  4. Replies:
    1
    Views:
    2,477
    Mark P
    Apr 6, 2007
  5. Xah Lee
    Replies:
    4
    Views:
    957
Loading...

Share This Page