New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CMake-based Xcode build fails to build any library #355
Comments
…ct). Targets with only object inputs do not work correctly with some generators (like Xcode, see issue weidai11#355). Defining these directly in terms of the source code files (rather than a reused set of object files) allows correct builds in such cases. This can now be controlled through a new option USE_INTERMEDIATE_OBJECTS_TARGET which defaults to ON.
Now open on the user list: Issue 335: CMake-based Xcode build fails to build any library |
I don't think this report is correct. Here you can see a cmake build of the current Github master on MacOS Sierra, Xcode-8.2.1, Macports-installed cmake-3.7.1 (though it worked on previous versions of Mac OS X, older Xcode, and older cmake):
We do care for cmake (to an extent), and we do care for Xcode (a lot). But I for one cannot reproduce your problem. P.S. Off-hand, the proposed change in #357 doesn't seem dangerous, so it should be OK to merge. But I'd like to see some more evidence that it is necessary. |
@mouse07410 The build for which you provide a log uses the Makefile generator, not Xcode. Here are my logs:
|
I can't duplicate the issue, but I suspect I am doing something wrong:
And then:
Would you be able to get Cmake display the output rather than hiding the commands? |
@noloader You are telling cmake to generate an Xcode project (by means of the
There is no useful output for the cryptopp-static target itself. It seems xcodebuild doesn't even invoke any commands for it - unless it has the dummy source file:
After digging a bit it seems that adding the dummy CPP file results in the addition of a single attribute in the target build settings (PFE_FILE_C_DIALECTS = c++) though adding only this attribute doesn't fix the problem. After adding the dummy cpp file it looks like this:
|
Ah, OK, I see some of what is going on... Running the
It appears Cmake/Xcode built a static archive called
Can you ask Cmake/Xcode to link against You should probably file a bug against Cmake. I'm thinking they should probably be doing more for you. That is, they either need to produce an artifact that's properly named; or they need to perform the copy so the expected artifact is available. Here's more about the symbols in
|
Let's see if the folks on Stack Overflow can help: Cmake generated Xcode project does not produce library artifacts? They have some very talented Cmake readers. Hopefully one of them will know what to do. Here's a few related questions.The first one may be the same as your problem, but there was no analysis, so its hard to tell. We know the library is being built; its just not being copied where it belongs. |
I have two points to make (no pun intended :) here.
In summary, I'd be OK with merging this fix. |
@HeinrichJanzing, @mouse07410, PR 357 was merged at Commit 89facf5599bd053b. |
…arget CMake: allow disabling the intermediate objects target (cryptopp-object).
I'm using CMake 3.6.1 and Xcode 8. I'm attempting to build cryptopp 5.6.5.
When attempting to build the static or shared library using cmake with the Xcode generator, the library itself is never created. The shared target fails due to the missing output file at some point while the static target claims to succeed despite the same lack of output.
It appears to be caused by (at least for CMake >= 2.8.8) the shared and static library targets having only object files as input. According to the documentation for cmake's add_library:
It would seem this is the case for Xcode. I see several options:
The text was updated successfully, but these errors were encountered: