The case insensitive #include statement horror...

S

Stephan Kuhagen

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
 
O

Ondra Holub

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.
 
S

Stephan Kuhagen

Ondra said:
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
 
O

Ondra Holub

Stephan Kuhagen napsal:
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.
 
R

Ron Natalie

Stephan said:
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.
 
S

Stephan Kuhagen

Ondra said:
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
 
V

Victor Bazarov

Stephan said:
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
 
R

rossum

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
 
S

Stephan Kuhagen

rossum said:
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
 
S

Stephan Kuhagen

Victor said:
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
 
?

=?iso-8859-1?q?Kirit_S=E6lensminde?=

Stephan said:
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
 
A

Alf P. Steinbach

* Stephan Kuhagen:
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. :)
 
S

Stephan Kuhagen

Alf said:
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
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top