Notes
(0024545) Markus Elfring (reporter) 2011-01-10 14:20 edited on: 2011-01-10 16:59	The message "CMake Error at cli/CMakeLists.txt:42 (add_executable)" currently points to the following line in this script. add_executable(cppcheck "${CPPCHECK_CLI_SOURCES}") Do I apply a wrong syntax?

(0024546) Brad King (manager) 2011-01-10 14:45	Take out the quotes: add_executable(cppcheck ${CPPCHECK_CLI_SOURCES}) The CPPCHECK_CLI_SOURCES variable must list the source files relative to the directory containing the call to add_executable: set(CPPCHECK_CLI_SOURCES myCLI1.cpp myCLI2.cpp subdir/myCLI3.cpp ../sibling/myCLI4.cpp )

(0024548) Brad King (manager) 2011-01-10 14:47	The issue tracker is not a good place to ask for help. Please bring discussion up in the CMake mailing list: http://www.cmake.org/mailman/listinfo/cmake [^] The error message provided by CMake 2.8.3 is already providing all the information CMake has about the problem.

(0024563) Markus Elfring (reporter) 2011-01-10 16:58	Are quotation marks really not allowed for variable substitution with the CMake add_executable function/command?

(0024564) Brad King (manager) 2011-01-10 17:06	I repeat: 0011677:0024548

(0024567) Markus Elfring (reporter) 2011-01-11 01:48 edited on: 2011-01-11 01:59	Thanks for your support.

(0024569) Markus Elfring (reporter) 2011-01-11 03:01 edited on: 2011-01-11 03:15	You are right. The function call "add_executable" from my initial description works if I omit the quotes around the passed parameter. I interpret this in a way that the constructed file name list should be acceptable for the build file generation process. I would like to point out that I have noticed a behaviour that I did not expect. Do I overlook a restriction specification in your documentation? http://cmake.org/cmake/help/cmake-2-8-docs.html#command:add_executable [^] An other article gives me the indication that quotation marks are appropriate for a couple of use cases with your programming language. http://cmake.org/Wiki/CMake/Language_Syntax#CMake_splits_arguments_unless_you_use_quotation_marks_or_escapes. [^] Is the displayed error message in this context mistakable and (partly) wrong?

(0024570) Markus Elfring (reporter) 2011-01-11 03:51	It seems that an other function like "ADD_CUSTOM_COMMAND" is also affected by a disagreement about the syntax handling for quotation marks. Description by Dieter Oberkofler: "the input line is too long" error after upgrading from 2.8.2 to 2.8.3 0011462:0024514

(0024571) David Cole (manager) 2011-01-11 07:19	Basic CMake syntax handling w.r.t. quotation marks is not a bug. Having the quotes in the wrong places in a CMakeLists file is a bug. But not in CMake... It takes a while to understand what needs double quotes and what doesn't need double quotes in a CMakeLists file. Perhaps this discussion will help: add_executable takes as its arguments: - the name of the executable - optional flags [WIN32 MACOSX_BUNDLE EXCLUDE_FROM_ALL] - a list of one or more source files Each argument that you put double quotes around in your CMakeLists.txt file is interpreted as a single argument to add_executable. So if you put double quotes around: "${source_files}" then it works... as long as ${source_files} is a list of exactly 1 source file. If it's more than 1, then add_executable tries to interpret it as 1 anyway because you put double quotes around it. Then, it will not be able to find it. However, that does not seem to be your problem here. You have a case where the list does actually contain exactly 1 file. If the file is not a full path name, then it must exist in the same directory with the CMakeLists file when you call add_executable. (Or it must be listed in other build rules as an output of a target built earlier...) So: do these files exist? If so, and CMake still reports an error, then that's the bug. If not, then CMake is telling you the exact problem by saying "Cannot find source file "filelister_unix.cpp"". That means the file does not exist. As Brad pointed out, this is really something to discuss on the mailing list because thousands of people read the mailing list and might be able to help you out. Only a handful of us read through bugs in the bug tracker. Especially when they're not really bugs. I'm going to resolve this bug. Please do not re-open this one... it is simply not a bug in CMake. If you have found a real problem with CMake itself, please open a different bug to report it after having discussed it first on the mailing list. Thanks, David

(0024585) Markus Elfring (reporter) 2011-01-11 10:30	> So if you put double quotes around: > "${source_files}" > then it works... as long as ${source_files} is a list of exactly 1 source file. Your view does not completely fit to my situation. 1. If I omit the quotation marks for passing of the mentioned parameter, the variable "CPPCHECK_CLI_SOURCES" contains a list of 29 file names for the desired compilation. The most result files are generated as expected at the current software development stage. 2. My expectation was that this should not change because of parameter quoting. The displayed error message shows only a single file name and not the whole list as a single long string (with 28 semicolons distributed over the text).

(0024588) David Cole (manager) 2011-01-11 10:40	> Your view does not completely fit to my situation. > 1. If I omit the quotation marks for passing of the mentioned parameter, the > variable "CPPCHECK_CLI_SOURCES" contains a list of 29 file names for the > desired compilation. The most result files are generated as expected at the > current software development stage. I guess I don't understand what you're saying. Are you saying it works exactly as you expect it with no errors when you pass it without quotation marks? If so, then the solution to your problem here is to pass it without quotation marks. > 2. My expectation was that this should not change because of parameter > quoting. The displayed error message shows only a single file name and not > the whole list as a single long string (with 28 semicolons distributed over > the text). Your expectation, while quite reasonable, is simply not how CMake works. Quoting of things in CMakeLists files is important, and you have to learn when to use them and when not to use them. You must be relatively new to CMake. Don't worry, after a couple weeks of trying to figure a few of these mysteries out, you'll get the hang of quoting things (or not) in CMakeLists files. I've been working with it for 6 years now, and I still sometimes confuse myself about where quotes are needed and where they're not. In this particular case, quotes are not needed, and in fact are harmful.

(0024706) Markus Elfring (reporter) 2011-01-15 06:46 edited on: 2011-01-15 07:13	I can reproduce the reported unexpected behaviour easily as my corresponding script example demonstrates this issue 'Clarification for quoting of parameters for "add_executable()"' in the mailing list archive. http://permalink.gmane.org/gmane.comp.programming.tools.cmake.user/33943 [^] http://www.mail-archive.com/cmake@cmake.org/msg33811.html [^] Would you like to improve the situation so that the wording of the mentioned error message will show an unchanged value of an input parameter?

(0024707) Brad King (manager) 2011-01-15 07:42	Okay, this entire report has been confused by the quoting discussion. Sorry. One can reproduce this simply with: add_executable(Bug11677 "does_not_exist/basename.cxx") and the reported error message does not include the "does_not_exist/" part.

(0024708) Brad King (manager) 2011-01-15 08:03	http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9cefce09 [^]

(0024710) Markus Elfring (reporter) 2011-01-15 09:14	Thanks for your improvement. Your test case variant fits to my situation partly. (The directory prefix is really usable for the software I try to update.) How will your tool react after your source code adjustment (in the member function "cmSourceFile::FindFullPath") if a single string was passed that looks like a CMake list because a list of (absolute) file names was stuffed together which were "accidentally" separated by semicolons?

(0024714) Brad King (manager) 2011-01-15 10:23	It will report the whole string. The list set(mysrc a.c /any/path/here/b.c) is stored as a string with semicolons. Then the quotes in add_executable(myexe "${mysrc}") tell CMake to treat the argument as a single string without separating the list elements back out by dividing at semicolons. The command receives source file a.c;/any/path/here/b.c which looks like a relative path with directory "a.c;/any/path/here" and file name "b.c". Now that the directory portion is included in the error message the original string will be reproduced, semicolons and all. Changing the code to not have quotes: add_executable(myexe ${mysrc}) tells CMake to separate the mysrc list so the command receives arguments a.c /any/path/here/b.c which is the intention. The ${} syntax is evaluated by the language before the command to which it is passed is even invoked. This is exactly the same as in bash shell syntax. We just use semicolons instead of whitespace to separate unqouted arguments.

(0024716) Markus Elfring (reporter) 2011-01-15 10:58	I would like to point out another interesting detail in your patch. The directory and file name are concatenated by a hard-coded slash at the moment. I assume that a configuration option for this name separator/delimiter might be needed because of portability. http://en.wikipedia.org/wiki/Path_%28computing%29 [^] I guess that this could become a topic for a corresponding feature request or clarification, couldn't it? Does a programming interface exist to retrieve the original/unchanged value from the affected input parameter?

(0024717) Brad King (manager) 2011-01-15 11:08	CMake always uses forward slashes internally. It converts them to the preferred slash direction of the native tools when generating the build system. The original path will be printed up to possible '\' -> '/' conversion. That doesn't affect the existence of the file.

(0024718) Markus Elfring (reporter) 2011-01-15 11:39	Thanks for your explanation. Now I find your handling of value reconstruction clear for the needed unambiguous error message.

Issue History
Date Modified	Username	Field	Change
2011-01-10 13:50	Markus Elfring	New Issue
2011-01-10 13:50	Markus Elfring	File Added: CMakeCache.txt.zip
2011-01-10 14:20	Markus Elfring	Note Added: 0024545
2011-01-10 14:45	Brad King	Note Added: 0024546
2011-01-10 14:47	Brad King	Note Added: 0024548
2011-01-10 14:47	Brad King	Status	new => closed
2011-01-10 14:47	Brad King	Assigned To	=> Brad King
2011-01-10 14:47	Brad King	Resolution	open => no change required
2011-01-10 16:58	Markus Elfring	Note Added: 0024563
2011-01-10 16:58	Markus Elfring	Status	closed => feedback
2011-01-10 16:58	Markus Elfring	Resolution	no change required => reopened
2011-01-10 16:59	Markus Elfring	Note Edited: 0024545
2011-01-10 17:06	Brad King	Note Added: 0024564
2011-01-10 17:06	Brad King	Status	feedback => closed
2011-01-10 17:06	Brad King	Resolution	reopened => no change required
2011-01-11 01:48	Markus Elfring	Note Added: 0024567
2011-01-11 01:48	Markus Elfring	Status	closed => feedback
2011-01-11 01:48	Markus Elfring	Resolution	no change required => reopened
2011-01-11 01:59	Markus Elfring	Note Edited: 0024567
2011-01-11 03:01	Markus Elfring	Note Added: 0024569
2011-01-11 03:01	Markus Elfring	Status	feedback => assigned
2011-01-11 03:08	Markus Elfring	Note Edited: 0024569
2011-01-11 03:15	Markus Elfring	Note Edited: 0024569
2011-01-11 03:51	Markus Elfring	Note Added: 0024570
2011-01-11 07:19	David Cole	Note Added: 0024571
2011-01-11 07:21	David Cole	Status	assigned => resolved
2011-01-11 07:21	David Cole	Fixed in Version	=> CMake 2.8.4
2011-01-11 07:21	David Cole	Resolution	reopened => no change required
2011-01-11 10:30	Markus Elfring	Note Added: 0024585
2011-01-11 10:30	Markus Elfring	Status	resolved => feedback
2011-01-11 10:30	Markus Elfring	Resolution	no change required => reopened
2011-01-11 10:40	David Cole	Note Added: 0024588
2011-01-11 10:40	David Cole	Status	feedback => resolved
2011-01-11 10:40	David Cole	Resolution	reopened => no change required
2011-01-15 06:46	Markus Elfring	Note Added: 0024706
2011-01-15 06:46	Markus Elfring	Status	resolved => feedback
2011-01-15 06:46	Markus Elfring	Resolution	no change required => reopened
2011-01-15 06:53	Markus Elfring	Note Edited: 0024706
2011-01-15 07:06	Markus Elfring	Note Edited: 0024706
2011-01-15 07:13	Markus Elfring	Note Edited: 0024706
2011-01-15 07:42	Brad King	Note Added: 0024707
2011-01-15 08:03	Brad King	Note Added: 0024708
2011-01-15 08:03	Brad King	Status	feedback => closed
2011-01-15 08:03	Brad King	Resolution	reopened => fixed
2011-01-15 09:14	Markus Elfring	Note Added: 0024710
2011-01-15 09:14	Markus Elfring	Status	closed => feedback
2011-01-15 09:14	Markus Elfring	Resolution	fixed => reopened
2011-01-15 10:23	Brad King	Note Added: 0024714
2011-01-15 10:58	Markus Elfring	Note Added: 0024716
2011-01-15 10:58	Markus Elfring	Status	feedback => assigned
2011-01-15 11:08	Brad King	Note Added: 0024717
2011-01-15 11:39	Markus Elfring	Note Added: 0024718
2011-01-17 09:25	Brad King	Status	assigned => closed
2011-01-17 09:25	Brad King	Resolution	reopened => fixed
2011-01-17 09:25	Brad King	Fixed in Version	CMake 2.8.4 =>
2011-01-31 16:03	David Cole	Fixed in Version	=> CMake 2.8.4
2011-01-31 16:03	David Cole	Target Version	=> CMake 2.8.4

Relationships