MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011677CMakeCMakepublic2011-01-10 13:502011-01-31 16:03
ReporterMarkus Elfring 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformopenSUSE 11.3OSLinuxOS Version2.6.37
Product VersionCMake-2-8 
Target VersionCMake 2.8.4Fixed in VersionCMake 2.8.4 
Summary0011677: Clarification of message "CMake Error in cli/CMakeLists.txt"
DescriptionI try to update some scripts which were published with the feature request "Add simple CMake build files".
https://sourceforge.net/apps/trac/cppcheck/ticket/1092#comment:5 [^]

The first configuration after some edits works as expected. But I was surprised by the message "Error in configuration process, project files may be invalid" in a dialogue box of the tool "CMake-GUI 2.8.1" for my generation try.

I stumble on the following log display.

The C compiler identification is GNU
The CXX compiler identification is GNU
Configuring done
CMake Error in cli/CMakeLists.txt:
  Cannot find source file "filelister_unix.cpp". Tried extensions .c .C .c++
  .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx


Now I try to repeat these steps with the graphical user interface from the package "http://www.cmake.org/files/v2.8/cmake-2.8.3-Linux-i386.sh". [^]

The corresponding log area displays the following informations:
The C compiler identification is GNU
The CXX compiler identification is GNU
Configuring done
CMake Error at cli/CMakeLists.txt:42 (add_executable):
  Cannot find source file "filelister_unix.cpp". Tried extensions .c .C .c++
  .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx

I have got doubts that the displayed informations are sufficient to resolve this in a "convenient" way because the mentioned file exists in a subdirectory so far.
-rw-r--r-- 1 elfring users 2446 10. Jan 10:38 /home/elfring/Projekte/cppcheck/lokal/lib/filelister_unix.cpp

Are there any chances to get more debugging details?
Steps To Reproduce
Additional InformationName : cmake Relocations: (not relocatable)
Version : 2.8.1 Vendor: openSUSE
Release : 3.4 Build Date: Di 06 Jul 2010 00:03:31 CEST
Install Date: Fr 16 Jul 2010 18:50:49 CEST Build Host: build33
Group : Development/Tools/Building Source RPM: cmake-2.8.1-3.4.src.rpm
Size : 20067305 License: BSD3c
Signature : RSA/8, Di 06 Jul 2010 00:06:19 CEST, Key ID b88b2fd43dbdc284
Packager : http://bugs.opensuse.org [^]
TagsNo tags attached.
Relationships
Attached Fileszip CMakeCache.txt.zip (2,936) 2011-01-10 13:50
https://public.kitware.com/Bug/file/3613/CMakeCache.txt.zip
Issue History
Date ModifiedUsernameFieldChange
2011-01-10 13:50Markus ElfringNew Issue
2011-01-10 13:50Markus ElfringFile Added: CMakeCache.txt.zip
2011-01-10 14:20Markus ElfringNote Added: 0024545
2011-01-10 14:45Brad KingNote Added: 0024546
2011-01-10 14:47Brad KingNote Added: 0024548
2011-01-10 14:47Brad KingStatusnew => closed
2011-01-10 14:47Brad KingAssigned To => Brad King
2011-01-10 14:47Brad KingResolutionopen => no change required
2011-01-10 16:58Markus ElfringNote Added: 0024563
2011-01-10 16:58Markus ElfringStatusclosed => feedback
2011-01-10 16:58Markus ElfringResolutionno change required => reopened
2011-01-10 16:59Markus ElfringNote Edited: 0024545bug_revision_view_page.php?bugnote_id=24545#r85
2011-01-10 17:06Brad KingNote Added: 0024564
2011-01-10 17:06Brad KingStatusfeedback => closed
2011-01-10 17:06Brad KingResolutionreopened => no change required
2011-01-11 01:48Markus ElfringNote Added: 0024567
2011-01-11 01:48Markus ElfringStatusclosed => feedback
2011-01-11 01:48Markus ElfringResolutionno change required => reopened
2011-01-11 01:59Markus ElfringNote Edited: 0024567bug_revision_view_page.php?bugnote_id=24567#r87
2011-01-11 03:01Markus ElfringNote Added: 0024569
2011-01-11 03:01Markus ElfringStatusfeedback => assigned
2011-01-11 03:08Markus ElfringNote Edited: 0024569bug_revision_view_page.php?bugnote_id=24569#r89
2011-01-11 03:15Markus ElfringNote Edited: 0024569bug_revision_view_page.php?bugnote_id=24569#r90
2011-01-11 03:51Markus ElfringNote Added: 0024570
2011-01-11 07:19David ColeNote Added: 0024571
2011-01-11 07:21David ColeStatusassigned => resolved
2011-01-11 07:21David ColeFixed in Version => CMake 2.8.4
2011-01-11 07:21David ColeResolutionreopened => no change required
2011-01-11 10:30Markus ElfringNote Added: 0024585
2011-01-11 10:30Markus ElfringStatusresolved => feedback
2011-01-11 10:30Markus ElfringResolutionno change required => reopened
2011-01-11 10:40David ColeNote Added: 0024588
2011-01-11 10:40David ColeStatusfeedback => resolved
2011-01-11 10:40David ColeResolutionreopened => no change required
2011-01-15 06:46Markus ElfringNote Added: 0024706
2011-01-15 06:46Markus ElfringStatusresolved => feedback
2011-01-15 06:46Markus ElfringResolutionno change required => reopened
2011-01-15 06:53Markus ElfringNote Edited: 0024706bug_revision_view_page.php?bugnote_id=24706#r117
2011-01-15 07:06Markus ElfringNote Edited: 0024706bug_revision_view_page.php?bugnote_id=24706#r118
2011-01-15 07:13Markus ElfringNote Edited: 0024706bug_revision_view_page.php?bugnote_id=24706#r119
2011-01-15 07:42Brad KingNote Added: 0024707
2011-01-15 08:03Brad KingNote Added: 0024708
2011-01-15 08:03Brad KingStatusfeedback => closed
2011-01-15 08:03Brad KingResolutionreopened => fixed
2011-01-15 09:14Markus ElfringNote Added: 0024710
2011-01-15 09:14Markus ElfringStatusclosed => feedback
2011-01-15 09:14Markus ElfringResolutionfixed => reopened
2011-01-15 10:23Brad KingNote Added: 0024714
2011-01-15 10:58Markus ElfringNote Added: 0024716
2011-01-15 10:58Markus ElfringStatusfeedback => assigned
2011-01-15 11:08Brad KingNote Added: 0024717
2011-01-15 11:39Markus ElfringNote Added: 0024718
2011-01-17 09:25Brad KingStatusassigned => closed
2011-01-17 09:25Brad KingResolutionreopened => fixed
2011-01-17 09:25Brad KingFixed in VersionCMake 2.8.4 =>
2011-01-31 16:03David ColeFixed in Version => CMake 2.8.4
2011-01-31 16:03David ColeTarget Version => CMake 2.8.4

Notes
(0024545)
Markus Elfring   
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   
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   
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   
2011-01-10 16:58   
Are quotation marks really not allowed for variable substitution with the CMake add_executable function/command?
(0024564)
Brad King   
2011-01-10 17:06   
I repeat: 0011677:0024548
(0024567)
Markus Elfring   
2011-01-11 01:48   
(edited on: 2011-01-11 01:59)
Thanks for your support.
(0024569)
Markus Elfring   
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   
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   
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   
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   
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   
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   
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   
2011-01-15 08:03   
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9cefce09 [^]
(0024710)
Markus Elfring   
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   
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   
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   
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   
2011-01-15 11:39   
Thanks for your explanation.

Now I find your handling of value reconstruction clear for the needed unambiguous error message.