[swift-dev] Request for review on Windows CMake changes

[Saleem Abdulrasool]

On Tue, Dec 12, 2017 at 4:47 PM, Wallacy <wallacyf at gmail.com> wrote:

> Has anyone considered the Bezel Build for swift?
>
> https://bazel.build/
>
> Seems to address these problems.


I'm sorry, but I fail to see how bazel would address any of these issues.
The flags are exported from LLVM's CMake infrastructure.  First of all, we
would have to recreate all the dependency information from LLVM to import
that into this new build system.  Next, we need to reconstruct parts of
clang to re-embed into the swift compiler.  We also now have the additional
cognitive overhead of switching build systems going between clang/LLVM and
swift.  We would lose the dependency tracking or need to reconstruct all of
that and maintain it.

The problems with the cross-compiling that Im referring to are not inherent
to CMake (although, I am slightly partial to the autotools approach to
cross-compilation), but rather the way that the tool is being used within
the context of swift.  As an example, libdispatch is extremely easy to
cross-compile thanks to its use of CMake.


>
> Em ter, 12 de dez de 2017 às 19:39, Saleem Abdulrasool via swift-dev <
> swift-dev at swift.org> escreveu:
>
>> On Sat, Dec 9, 2017 at 9:21 AM, David Zarzycki via swift-dev <
>> swift-dev at swift.org> wrote:
>>
>>> Can somebody please also speak up to why Windows needs to remove the
>>> "-Wl,-z,defs” from CXX_FLAGS? At the very least, I’d like to see the
>>> project-wide removal of this useful flag limited to just the Windows builds.
>>>
>>
>> Currently, the way that swift approaches building goes against the way
>> that CMake intended cross-compilation to work.  The result is that we end
>> up having to do a number of fairly nasty things to get things to work.
>> Options are not spelt the same way nor do all options make sense on all
>> targets.  `-z defs` is an ELF specific option.  However, because we use the
>> same rules for all targets using the build as the host, we cannot simply
>> filter based on the target.  Instead, this needs to be done at the lowest
>> possible layer when we know if the build is ELF or COFF or MachO.  That
>> said, I think that exporting this flag from LLVM is not the right thing and
>> that swift should be re-adding that flag if it so decides to use (which for
>> ELF targets, it really is a good idea).
>>
>> I think that if we start splitting things up and using ExternalProject to
>> joining the various pieces we should be able to accommodate that and re-use
>> the cross-compilation support in CMake.  I think that there is some work
>> that has been done there for the SDK overlay and libdispatch.
>>
>>
>>>
>>> On Dec 8, 2017, at 20:36, Thomas Roughton via swift-dev <
>>> swift-dev at swift.org> wrote:
>>>
>>> Hi all,
>>>
>>> I've had a PR (https://github.com/apple/swift/pull/13140) that's been
>>> open for about 10 days with a few CMake changes to fix the Windows
>>> cross-compile build. I wasn't sure who best to ask to review it, but was
>>> suggested to post here with it.
>>>
>>> Could someone familiar with that area maybe add themselves as a reviewer
>>> and then later take a look when they get a chance (even if that's not for a
>>> few weeks)? There's no particular urgency, but it'd be ideal if possible to
>>> have the changes in before it needs to be rebased too many times.
>>>
>>> Thanks,
>>> Thomas
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>
>>>
>>
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171212/0d7e72fc/attachment.html>