MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0016040CMakeCMakepublic2016-03-30 16:572016-06-10 14:31
ReporterColin Cornaby 
Assigned ToGregor Jasny 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformXcode 7.3OSMac OSOS Version10.11
Product VersionCMake 3.5.1 
Target VersionFixed in Version 
Summary0016040: Generated Xcode Projects Have Wrong Paths to Object Library Dependencies
DescriptionWe have a CMake project that has object libraries, and then a parent build target that wraps those object libraries into a static library. When I generate the Xcode output, the parent build target is referencing different paths than what the .o's were outputted to.

I have a patch that fixes the issue, but I wanted to open a bug first, especially if I'm duplicating something (apologies, this is my first CMake bug.)

The section of code that seems to be the issue in the Xcode generator is here:
cmGlobalXCodeGenerator::GetObjectsNormalDirectory(
  const std::string &projName,
  const std::string &configName,
  const cmGeneratorTarget *t) const
{
  std::string dir =
    t->GetLocalGenerator()->GetCurrentBinaryDirectory();
  dir += "/";
  dir += projName;
  dir += ".build/";
  dir += configName;
  dir += "/";
  dir += t->GetName();
  dir += ".build/Objects-normal/";

  return dir;
}

There are a few things wrong here:
- The configuration name should be part of this path. Specifically the section of that path that is "foo.build/release" should be "foo.build/release-iphoneos". This behavior could be different for Mac targets, but I'm pretty sure it isn't. One reason I'm not straight submitting the patch yet.
- The .o files get written to the temporary objects directory, not the binary output directory. I've wrapped this in a new function:
std::string
cmGlobalXCodeGenerator::GetTemporaryFilesDirectory(
                                                  const std::string &projName,
                                                  const std::string &configName,
                                                  const cmGeneratorTarget *t) const
{
    std::string dir =
    t->GetLocalGenerator()->GetCurrentBinaryDirectory();
    dir += "/";
    dir += projName;
    dir += ".build/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/";
    
    return dir;
}

I've then altered a few functions. GetObjectsNormalDirectory becomes:
//----------------------------------------------------------------------------
std::string
cmGlobalXCodeGenerator::GetObjectsNormalDirectory(
  const std::string &projName,
  const std::string &configName,
  const cmGeneratorTarget *t) const
{
    std::string dir = GetTemporaryFilesDirectory(projName, configName, t);
  dir += t->GetName();
  dir += ".build/Objects-normal/";

  return dir;
}

The build setting creation gets altered a bit a well with:
if(this->XcodeVersion >= 21)
      {
      std::string pncdir = this->GetObjectsNormalDirectory(
                                                           this->CurrentProject, configName, gtgt);
      std::string tempdir = this->GetTemporaryFilesDirectory(
                                                           this->CurrentProject, configName, gtgt);
      buildSettings->AddAttribute("CONFIGURATION_BUILD_DIR",
                                  this->CreateString(pncdir.c_str()));
      buildSettings->AddAttribute("CONFIGURATION_TEMP_DIR",
                                      this->CreateString(tempdir.c_str()));
      }
    else
      {
      buildSettings->AddAttribute("OBJROOT",
                                  this->CreateString(pndir.c_str()));
      pndir = this->GetObjectsNormalDirectory(
        this->CurrentProject, configName, gtgt);
      }
    }

Again, mostly submitting this bug because I'm new to Cmake and I don't know if this is patching on top of behavior that is platform dependent. Please let me know if there is something I am missing here, or if I'm breaking something else with these patches!

(I'm attaching a Git patch as well)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filespatch 0001-Fixes-for-.o-generation.patch (3,497) 2016-03-30 16:57
https://public.kitware.com/Bug/file/5663/0001-Fixes-for-.o-generation.patch
zip test.zip (36,037) 2016-04-07 17:32
https://public.kitware.com/Bug/file/5670/test.zip
patch 0001-Fixes-for-.o-generation-FIXED.patch (3,252) 2016-04-14 18:02
https://public.kitware.com/Bug/file/5677/0001-Fixes-for-.o-generation-FIXED.patch
Issue History
Date ModifiedUsernameFieldChange
2016-03-30 16:57Colin CornabyNew Issue
2016-03-30 16:57Colin CornabyFile Added: 0001-Fixes-for-.o-generation.patch
2016-03-31 03:58Gregor JasnyAssigned To => Gregor Jasny
2016-03-31 03:58Gregor JasnyStatusnew => assigned
2016-03-31 04:00Gregor JasnyNote Added: 0040773
2016-03-31 12:36Colin CornabyNote Added: 0040777
2016-04-07 17:32Colin CornabyFile Added: test.zip
2016-04-07 17:33Colin CornabyNote Added: 0040826
2016-04-07 17:34Colin CornabyNote Added: 0040827
2016-04-14 18:02Colin CornabyNote Added: 0040863
2016-04-14 18:02Colin CornabyFile Added: 0001-Fixes-for-.o-generation-FIXED.patch
2016-06-10 14:29Kitware RobotNote Added: 0042971
2016-06-10 14:29Kitware RobotStatusassigned => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0040773)
Gregor Jasny   
2016-03-31 04:00   
Hello,

your patch seems to have some whitespace/tab issues. could you please clean them up and re-attach the patch?

I'd also like to create a test for this behavior. Could you please provide a minimal example and describe what to (not) look for in the generated xcodeproj?

Thanks,
Gregor
(0040777)
Colin Cornaby   
2016-03-31 12:36   
Thanks! I'm consuming this CMake project, but I don't know much about implementing a CMake project myself. I'll work with the author of this CMake project to boil it down to a sample. I'll clean up the white space too.
(0040826)
Colin Cornaby   
2016-04-07 17:33   
Sorry for the delay, had to learn some Cmake. The attached project is showing the problem for me. I have a sub target that is an object library, and a parent that depends on it. The parent target is reference the .o in a different place than the sub target object library is generating it.

Command I'm using to invoke Cmake is:
cmake -G "Xcode" -DCMAKE_BUILD_TYPE=Release
(0040827)
Colin Cornaby   
2016-04-07 17:34   
Oh, I also have cleaning up the white spaces on my list of things to do, just wanted to make sure as a CMake newbie I wasn't missing anything first.
(0040863)
Colin Cornaby   
2016-04-14 18:02   
Uploading a new diff. I think it fixes the spacing issues.
(0042971)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.