(0022863)
Eric NOULARD (developer)
2010-11-04 17:02

uploaded patch from Rolf

(0023302)
James Bigler (developer)
2010-11-16 14:44

http://www.cmake.org/pipermail/cmake/2010-November/040843.html [^]

This issue is also with at least the 2008 version of VS and setting the COMPILE_FLAGS property. I also noted it with the 2.6.4 version of CMake, but that ship has long since sailed.

(0023304)
Bill Hoffman (manager)
2010-11-16 15:29

I am not sure we want to fix this.... It is by design. Language "C" means a compiled C file even if the extension is not known by the compiler. HEADER_FILE_ONLY is the property for specifying that something should not be compiled even if it ends in something the compiler would normally compile like .c. If you put this change in it would break tons of stuff. Saying something is language "C" has always meant compile it for as long as we have had the property in CMake.

(0023305)
Eric NOULARD (developer)
2010-11-16 16:43

Then may be the doc should be updated in order to be more explicit:

LANGUAGE
       What programming language is the file.

       A property that can be set to indicate what programming language the
       source file is. If it is not set the language is determined based on
       the file extension. Typical values are CXX C etc.

Adding something like
"Setting this property for a file means this file has to be compiled.
Do not set this for header or not to be compiled files."

Basically it's simple to understand "HEADER_FILE_ONLY" as
"not to be compiled" whereas
the implication "LANGUAGE" ==> "has to be compiled" is not obvious.
The setting of "COMPILE_FLAGS" is more obvious though.

(0023306)
Bill Hoffman (manager)
2010-11-16 16:55

OK, a documentation change is in order. But I don't think there is a need to change the way it works.

(0023307)
James Bigler (developer)
2010-11-16 17:29

I can query the LANGUAGE property of a header file and it will say C or CXX. Also, if I query the HEADER_FILE_ONLY property it doesn't have one until presumably later.

So what do you think about the issue of setting the COMPILE_FLAGS on a file and it going from a header file to a now compiled file?

(0023573)
Patrik Gornicz (reporter)
2010-11-29 13:47

With respect to setting the COMPILE_FLAGS on header files ...

I just encountered this when I added support for pre-compiled headers to our source tree. Which is a case when you want to set a compile flag for the pre-compiled header and a different compile flag for all other source files. So setting the COMPILE_FLAGS variable on the target isn't quite right because the pre-compiled header would get both flags. Hence, I wrote a little function that takes the pre-compiled header and a list of source files (the same list of source files that is passed to add_library or add_executable) and sets the COMPILE_FLAGS (and OBJECT_OUTPUTS and OBJECT_DEPENDS) properties as appropriate.

Perhaps the most relevant thing to note though is that the nmake and gmake generators don't end up compiling a header file when COMPILE_FLAGS is set, it's only the VS2008 generator I've seen do it.

I'd like to see the COMPILE_FLAGS behavior fixed so I can remove a regular expression hack I added to work around this unexpected side effect.

Well that's my two cents.

(0024198)
David Cole (manager)
2010-12-16 07:32

According to this CMake mailing list email:
http://www.cmake.org/pipermail/cmake/2010-December/041399.html [^]

The same thing happens when you use:

set_source_files_properties(./fileToExclude.c
PROPERTIES HEADER_FILE_ONLY TRUE)

Therefore, at least that needs to be addressed for real. It's not just a documentation bug... And it's not just people trying to mark header files as "c" files... It's also people trying to mark c files as non-compiling... Which should be a legitimate use case, shouldn't it?

(0024291)
Bill Hoffman (manager)
2010-12-20 15:35

OK, I have a fix for the issue on the mailing list, in next now:
merge topic 'vs2010_header_only_fix' into next

It only showed up when C and C++ code was in a library and one of the .c or .cxx files was marked as header only.

(0024292)
Bill Hoffman (manager)
2010-12-20 15:49

All fixes have been pushed to CMake next.

Issue History
Date Modified	Username	Field	Change
2010-11-04 17:01	Eric NOULARD	New Issue
2010-11-04 17:02	Eric NOULARD	File Added: 0001-fix-MSVC2010-generator-writing-wrong-closing-tag.patch
2010-11-04 17:02	Eric NOULARD	Note Added: 0022863
2010-11-10 13:06	David Cole	Assigned To	=> Bill Hoffman
2010-11-10 13:06	David Cole	Status	new => assigned
2010-11-10 13:06	David Cole	Target Version	=> CMake 2.8.4
2010-11-16 14:44	James Bigler	Note Added: 0023302
2010-11-16 15:29	Bill Hoffman	Note Added: 0023304
2010-11-16 16:43	Eric NOULARD	Note Added: 0023305
2010-11-16 16:55	Bill Hoffman	Note Added: 0023306
2010-11-16 17:29	James Bigler	Note Added: 0023307
2010-11-29 13:47	Patrik Gornicz	Note Added: 0023573
2010-12-14 18:52	David Cole	Relationship added	has duplicate 0010652
2010-12-16 07:32	David Cole	Note Added: 0024198
2010-12-16 08:48	David Cole	Severity	minor => major
2010-12-20 15:35	Bill Hoffman	Note Added: 0024291
2010-12-20 15:49	Bill Hoffman	Note Added: 0024292
2010-12-20 15:49	Bill Hoffman	Status	assigned => closed
2010-12-20 15:49	Bill Hoffman	Resolution	open => fixed
2011-01-17 10:44	David Cole	Fixed in Version	=> CMake 2.8.4

Notes
(0022863) Eric NOULARD (developer) 2010-11-04 17:02	uploaded patch from Rolf

(0023302) James Bigler (developer) 2010-11-16 14:44	http://www.cmake.org/pipermail/cmake/2010-November/040843.html [^] This issue is also with at least the 2008 version of VS and setting the COMPILE_FLAGS property. I also noted it with the 2.6.4 version of CMake, but that ship has long since sailed.

(0023304) Bill Hoffman (manager) 2010-11-16 15:29	I am not sure we want to fix this.... It is by design. Language "C" means a compiled C file even if the extension is not known by the compiler. HEADER_FILE_ONLY is the property for specifying that something should not be compiled even if it ends in something the compiler would normally compile like .c. If you put this change in it would break tons of stuff. Saying something is language "C" has always meant compile it for as long as we have had the property in CMake.

(0023305) Eric NOULARD (developer) 2010-11-16 16:43	Then may be the doc should be updated in order to be more explicit: LANGUAGE What programming language is the file. A property that can be set to indicate what programming language the source file is. If it is not set the language is determined based on the file extension. Typical values are CXX C etc. Adding something like "Setting this property for a file means this file has to be compiled. Do not set this for header or not to be compiled files." Basically it's simple to understand "HEADER_FILE_ONLY" as "not to be compiled" whereas the implication "LANGUAGE" ==> "has to be compiled" is not obvious. The setting of "COMPILE_FLAGS" is more obvious though.

(0023306) Bill Hoffman (manager) 2010-11-16 16:55	OK, a documentation change is in order. But I don't think there is a need to change the way it works.

(0023307) James Bigler (developer) 2010-11-16 17:29	I can query the LANGUAGE property of a header file and it will say C or CXX. Also, if I query the HEADER_FILE_ONLY property it doesn't have one until presumably later. So what do you think about the issue of setting the COMPILE_FLAGS on a file and it going from a header file to a now compiled file?

(0023573) Patrik Gornicz (reporter) 2010-11-29 13:47	With respect to setting the COMPILE_FLAGS on header files ... I just encountered this when I added support for pre-compiled headers to our source tree. Which is a case when you want to set a compile flag for the pre-compiled header and a different compile flag for all other source files. So setting the COMPILE_FLAGS variable on the target isn't quite right because the pre-compiled header would get both flags. Hence, I wrote a little function that takes the pre-compiled header and a list of source files (the same list of source files that is passed to add_library or add_executable) and sets the COMPILE_FLAGS (and OBJECT_OUTPUTS and OBJECT_DEPENDS) properties as appropriate. Perhaps the most relevant thing to note though is that the nmake and gmake generators don't end up compiling a header file when COMPILE_FLAGS is set, it's only the VS2008 generator I've seen do it. I'd like to see the COMPILE_FLAGS behavior fixed so I can remove a regular expression hack I added to work around this unexpected side effect. Well that's my two cents.

(0024198) David Cole (manager) 2010-12-16 07:32	According to this CMake mailing list email: http://www.cmake.org/pipermail/cmake/2010-December/041399.html [^] The same thing happens when you use: set_source_files_properties(./fileToExclude.c PROPERTIES HEADER_FILE_ONLY TRUE) Therefore, at least that needs to be addressed for real. It's not just a documentation bug... And it's not just people trying to mark header files as "c" files... It's also people trying to mark c files as non-compiling... Which should be a legitimate use case, shouldn't it?

(0024291) Bill Hoffman (manager) 2010-12-20 15:35	OK, I have a fix for the issue on the mailing list, in next now: merge topic 'vs2010_header_only_fix' into next It only showed up when C and C++ code was in a library and one of the .c or .cxx files was marked as header only.

(0024292) Bill Hoffman (manager) 2010-12-20 15:49	All fixes have been pushed to CMake next.