MantisBT - CMake
View Issue Details
0008943CMakeCMakepublic2009-04-29 04:362010-10-06 14:35
Rolf Eike Beer 
Bill Hoffman 
normalminoralways
closedfixed 
CMake-2-6 
CMake 2.8.3CMake 2.8.3 
0008943: NMake Makefiles does not include files with uppercase extensions
One project had FOO.CPP and FOO.H in their list of project files. While Visual Studio builds correctly built them (minor bug: they were not put into the "Source Files" and "Header Files" groups) NMake did not. I assume that they were simply not put in the list of target files. Renaming them to FOO.cpp and FOO.h fixed that.
No tags attached.
related to 0010610closed Bill Hoffman VS2010 generator does not handle C++ files with upper case CPP extension 
zip cmake_8943.zip (1,136) 2009-05-11 10:22
https://public.kitware.com/Bug/file/2229/cmake_8943.zip
Issue History
2009-04-29 04:36Rolf Eike BeerNew Issue
2009-04-29 09:34Bill HoffmanStatusnew => assigned
2009-04-29 09:34Bill HoffmanAssigned To => Bill Hoffman
2009-04-29 09:35Bill HoffmanNote Added: 0016242
2009-05-11 10:22Rolf Eike BeerFile Added: cmake_8943.zip
2010-05-04 14:35Bill HoffmanRelationship addedrelated to 0010610
2010-08-25 07:10David ColeNote Added: 0021939
2010-08-25 08:40Rolf Eike BeerNote Added: 0021947
2010-08-25 11:07David ColeNote Added: 0021955
2010-08-25 13:41Rolf Eike BeerNote Added: 0021962
2010-08-31 17:52David ColeTarget Version => CMake 2.8.3
2010-09-02 14:41Bill HoffmanNote Added: 0022077
2010-09-08 09:57Bill HoffmanNote Added: 0022133
2010-09-08 09:57Bill HoffmanStatusassigned => closed
2010-09-08 09:57Bill HoffmanResolutionopen => fixed
2010-10-06 14:35David ColeFixed in Version => CMake 2.8.3

Notes
(0016242)
Bill Hoffman   
2009-04-29 09:35   
Can you provide an example?
(0021939)
David Cole   
2010-08-25 07:10   
One of the concerns here is that "C" is ambiguous: on some Unix systems, "C" is different than "c" and they map to different languages: "C" is C++ and "c" is C. Boo, case sensitive file systems.

On Windows, C and c are the same, and they both mean it's a "C" language file.

What should CMake do to resolve such ambiguities?
Should we make "C" mean C++ where appropriate, and mean C elsewhere...?
Or should we enforce that "C" always means one or the other?
Or should we give control to the end user to tell us about these mappings?
(0021947)
Rolf Eike Beer   
2010-08-25 08:40   
Yes, for "C" (and maybe "H") there is a problem. But what currently happens is that these files get added to Visual Studio projects and are ignored COMPLETELY for NMake projects. So this would build with MSVC but not with NMake as there the symbols from the second file would be missing.

What about just printing a dev warning "this filename could be both C and C++, please set the source file properties with ... to avoid this, using XXX now", where XXX is the default language specified for that project. If that is not specified that of any random other file in the project. Or C. Or whatever.

But _my_ problem here was that a file named "xx.CPP" was ignored in an NMake build even if I put it into the source files list. Silenty. That must not ever happen. And it worked with MSVC.
(0021955)
David Cole   
2010-08-25 11:07   
So, this bug should really be called "Please produce a warning when I add a source file with an extension that CMake does not know about."

It's tricky, though, because we allow you to add *.txt and *.htm and *.pdf files to libraries and executables so that they show up in the Visual Studio and Xcode IDEs, for example. So you don't want to produce warnings for all of those files. And that set of extensions is completely arbitrary. I wouldn't want to add a list of extensions that we *don't* warn about.

So the warning would have to be off by default, or easily switched off, so as not to annoy the many who are using this "feature" currently.
(0021962)
Rolf Eike Beer   
2010-08-25 13:41   
Just to get you right:

-only those files are added as sources to NMake that are known of
-all sources are added to MSVC builds

And that everything worked as expected with MSVC was just that it took the ".CPP" as ".cpp" and used it as normal source instead of ignoring it like it would have done with ".pdf"?

There should be at least a warning if the extension matches another "source" extension if it is compared case insensitive, as this can likely happen when you copy files around and any Windows filesystem is involved.
(0022077)
Bill Hoffman   
2010-09-02 14:41   
I have pushed a fix for this to next.
(0022133)
Bill Hoffman   
2010-09-08 09:57   
This is as fixed as it will get. .CPP now works on WIN32. Several unix compilers and versions of gcc do not accept this extension, so I would not recommended it for a project that is supposed to work on windows and linux.