On 01/13/2016 06:17 PM, Eric Wing wrote: > Under the hood, I think the LLVM linker can handle all of these > through ld. But I think the thing that is tripping me up is that Swift > seems to need to link against some additional libraries which are not > needed in the pure C case. The swiftc command seems to know how to > automatically link in those extra dependencies (and I don't need to > add all the search paths to where the Swift core libraries are > located).
That is the same as for C++. See CMAKE_PARSE_IMPLICIT_LINK_INFO and the call to it in "Modules/CMakeDetermineCompilerABI.cmake". That is responsible for extracting the implicit link information passed by a given language compiler's front-end. We'll need to extract that for Swift. > Anyway, I tried bumping up CMAKE_Swift_LINKER_PREFERENCE to 40. (Same > as Java). But it didn't seem to do anything for me. Where did you add the code to set it? > I just tried not filtering the current primary file from the list. It > still worked. So maybe we can get away with not filtering that. Great. It will be simplest to list all the sources in every call and then repeat the one that is current. > Anyway, it seems like adding SOURCES is the next step. Any hints on > how to do that? The cmLocalGenerator::ExpandRuleVariable method does the placeholder substitution. It relies on values in the RuleVariables structure to be populated by the calling generator. The Makefile generator populates that for the compile line here: cmMakefileTargetGenerator::WriteObjectBuildFile and the Ninja generator here: cmNinjaTargetGenerator::WriteCompileRule cmNinjaTargetGenerator::WriteObjectBuildStatement Note that for Ninja we actually convert our placeholders to Ninja rule placeholders and then provide the values on the actual build statement line. You should be able to call this->GeneratorTarget->GetObjectSources(objectSources, config); to get the list of source files and then filter it based on sf->GetLanguage(). The name "<SOURCES>" is not very good because it does not specify how any filtering is done. Perhaps a special case name such as "<Swift-SOURCES>" would be better. Do we know that there is a one-to-one mapping between libraries and Swift modules? -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
