View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0008943 | CMake | CMake | public | 2009-04-29 04:36 | 2010-10-06 14:35 | ||||
Reporter | Rolf Eike Beer | ||||||||
Assigned To | Bill Hoffman | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | CMake-2-6 | ||||||||
Target Version | CMake 2.8.3 | Fixed in Version | CMake 2.8.3 | ||||||
Summary | 0008943: NMake Makefiles does not include files with uppercase extensions | ||||||||
Description | 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. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | cmake_8943.zip [^] (1,136 bytes) 2009-05-11 10:22 | ||||||||
Relationships | ||||||
|
Relationships |
Notes | |
(0016242) Bill Hoffman (manager) 2009-04-29 09:35 |
Can you provide an example? |
(0021939) David Cole (manager) 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 (developer) 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 (manager) 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 (developer) 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 (manager) 2010-09-02 14:41 |
I have pushed a fix for this to next. |
(0022133) Bill Hoffman (manager) 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. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2009-04-29 04:36 | Rolf Eike Beer | New Issue | |
2009-04-29 09:34 | Bill Hoffman | Status | new => assigned |
2009-04-29 09:34 | Bill Hoffman | Assigned To | => Bill Hoffman |
2009-04-29 09:35 | Bill Hoffman | Note Added: 0016242 | |
2009-05-11 10:22 | Rolf Eike Beer | File Added: cmake_8943.zip | |
2010-05-04 14:35 | Bill Hoffman | Relationship added | related to 0010610 |
2010-08-25 07:10 | David Cole | Note Added: 0021939 | |
2010-08-25 08:40 | Rolf Eike Beer | Note Added: 0021947 | |
2010-08-25 11:07 | David Cole | Note Added: 0021955 | |
2010-08-25 13:41 | Rolf Eike Beer | Note Added: 0021962 | |
2010-08-31 17:52 | David Cole | Target Version | => CMake 2.8.3 |
2010-09-02 14:41 | Bill Hoffman | Note Added: 0022077 | |
2010-09-08 09:57 | Bill Hoffman | Note Added: 0022133 | |
2010-09-08 09:57 | Bill Hoffman | Status | assigned => closed |
2010-09-08 09:57 | Bill Hoffman | Resolution | open => fixed |
2010-10-06 14:35 | David Cole | Fixed in Version | => CMake 2.8.3 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |