MantisBT - CMake
View Issue Details
0008211CMakeCMakepublic2008-12-02 12:122014-06-02 08:37
David Karr 
Bill Hoffman 
normalminoralways
closedfixed 
CMake-2-6 
 
0008211: cmTarget::setType uses this->Makefile before it is defined
In the function cmTarget::setType, the following lines occur:

  if(type == cmTarget::INSTALL_FILES ||
     type == cmTarget::INSTALL_PROGRAMS ||
     type == cmTarget::INSTALL_DIRECTORY)
    {
    this->Makefile->
      IssueMessage(cmake::INTERNAL_ERROR,
                   "SetType called on cmTarget for INSTALL_FILES, "
                   "INSTALL_PROGRAMS, or INSTALL_DIRECTORY ");
    return;
    }

But in the three places where cmTarget::setType is called, it is called on a newly-created cmTarget whose Makefile has not yet been set. This can be confirmed by recompiling CMake with the following lines inserted at the start of the body of cmTarget::setType

  std::cerr << name << " makefile " <<
   (this->Makefile ? "OK" : "DOES NOT EXIST") << std::endl;
  type = cmTarget::INSTALL_FILES;

This simulates the occurrence of an internal error elsewhere in CMake. When the modified copy of CMake is used to generate a typical Visual Studio 9 "solution", it crashes immediately after printing out the text indicating that the makefile "does not exist".

This problem would be masked in normal operation, because the internal error should not occur. But if the internal error ever DID occur, the error messaging code would be useless.

Calling cmTarget::setMakefile before cmTarget::setType does not appear to be a valid resolution of this error, since that function requires the cmTarget type to be set already. Passing the makefile as an additional argument to cmTarget::setType may be a viable option.
No tags attached.
Issue History
2008-12-02 12:12David KarrNew Issue
2008-12-02 12:26Bill HoffmanStatusnew => assigned
2008-12-02 12:26Bill HoffmanAssigned To => Brad King
2008-12-02 12:40Brad KingNote Added: 0014270
2008-12-02 12:40Brad KingAssigned ToBrad King => Bill Hoffman
2013-11-02 10:13Stephen KellyNote Added: 0034321
2013-11-02 10:13Stephen KellyStatusassigned => resolved
2013-11-02 10:13Stephen KellyResolutionopen => fixed
2014-06-02 08:37Robert MaynardNote Added: 0035985
2014-06-02 08:37Robert MaynardStatusresolved => closed

Notes
(0014270)
Brad King   
2008-12-02 12:40   
This is why I'm a fan of constructor arguments which avoid creating objects in invalid states.

Bill, you were the one that wrote the code in question. I just had abort() there since this case is not supposed to be hit.
(0034321)
Stephen Kelly   
2013-11-02 10:13   
This seems to be obsolete.
(0035985)
Robert Maynard   
2014-06-02 08:37   
Closing resolved issues that have not been updated in more than 4 months.