<div dir="ltr"><div><br></div>On Tue, Jan 31, 2017 at 8:13 AM, Philippe Hausler via swift-corelibs-dev <span dir="ltr"><<a href="mailto:swift-corelibs-dev@swift.org" target="_blank">swift-corelibs-dev@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>So there are a few issues that would be a bit tricky to deal with:</div><div><br></div><div>SwiftPM uses Foundation so you would have to devise some way to build SwiftPM either without Foundation (which seems sub-optimal or replication of effort/code), directly importing parts of Foundation into the code-base for SwiftPM which might result in a synchronization issue of code, or a last-build result re-build of Foundation used in SwiftPM which seems like a pain when it comes to first time setup.</div><div><br></div><div>Foundation’s build environment is a bit tricky since it is not just plain C, we have assembly and some really funky linker tricks that might pose an issue. Also it might be a bit difficult to build CoreFoundation as it’s own target (as it stands now you can technically build CF without swift and use that independently on Linux - which elides the need to publish a separate CFLite).</div></div></blockquote><div><br></div><div>Note that you can have C and Swift targets in SwiftPM (and also statically link them) but I guess it will be difficult to get around the assembly and linker tricks. We do allow passing arbitrary compiler flags during invocation which are a workaround until we have a build settings story.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>From previous build infrastructure efforts that I have undertaken; the general consensus is that using SwiftPM would be nice but it doesn’t offer enough of a compelling reason to switch and complicate the rest of the Swift build process (which is already very complex).</div><div><br></div></div></blockquote><div><br></div><div>Daniel mentioned that we could add support for building Foundation with SwiftPM but not do it in the overall Swift build process, which I think makes sense and might be a nice thing for beginners. It is also very convenient for regular development, for e.g. most of the time I use a trunk snapshot from <a href="http://swift.org">swift.org</a> to develop SwiftPM. There are hardly any issues esp. since Swift 3 and syntax stability. And of course there is Swift CI to catch any issue before merging.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>Now the other alternative is that Foundation could be built with cmake. That has been something I have explored and it shows some promise. However as for fish to fry, it is a very small one. </div><div><br></div><div>Now I think fixing the dirty file bits from the build script might be a good thing to fix even without changing the build infrastructure. I have tried to fix this problem a few times but it ends up getting really complex really quickly.</div><div><br></div><div>If you want to dive into the current build system or perhaps look at cmake let me know if there are things that I can help out to clarify.</div><div><br></div><div>P.S. what slack server are you discussing this on? I was un-aware of any slack servers setup for swift.</div><br></div></blockquote><div><br></div><div>SwiftPM has an "unofficial" slack team, you can join here: <a href="http://swift-package-manager.herokuapp.com">http://swift-package-manager.herokuapp.com</a></div><div>More info here: <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160530/000497.html">https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160530/000497.html</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><span class="gmail-"><div>On Jan 30, 2017, at 4:49 PM, Robert F Dickerson via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" target="_blank">swift-corelibs-dev@swift.org</a>> wrote:</div><br class="gmail-m_-1994439752551623340Apple-interchange-newline"></span><div><div><p><span class="gmail-">This has probably been discussed in the past, but wanted to revisit the idea of using native Swift tools to build Foundation. I brought this up in the Slack group, and it seemed to be warmly received- although probably still not simple because of some cyclical dependency issues in the build process.<br><br>But, I think that there would be a lot of value in being able to build Foundation (and CoreFoundation) only using SwiftPM, in other words, simply with `swift build`. <br><br>Now that SwiftPM is improving its ability to pass in compilation flags more easily and C module compilation. I think that the project could be restructured to make this work. What would be the obstacles for getting this working?<br><br>
</span></p><table border="0" cellspacing="0" cellpadding="0"><tbody><tr valign="top"><td width="109" rowspan="3" valign="middle"><span id="gmail-m_-1994439752551623340cid:1__=09BB0A2ADF979F128f9e8a93df938690918c09B@"><ecblank.gif></span></td><td width="206"><span id="gmail-m_-1994439752551623340cid:1__=09BB0A2ADF979F128f9e8a93df938690918c09B@"><ecblank.gif></span></td></tr>
<tr valign="top"><td width="206" valign="bottom"><span id="gmail-m_-1994439752551623340cid:1__=09BB0A2ADF979F128f9e8a93df938690918c09B@"><ecblank.gif></span></td></tr>
<tr valign="top"><td width="206" valign="middle"><span id="gmail-m_-1994439752551623340cid:1__=09BB0A2ADF979F128f9e8a93df938690918c09B@"><ecblank.gif></span></td></tr>
<tr valign="top"><td width="315" colspan="2" valign="middle"><span id="gmail-m_-1994439752551623340cid:1__=09BB0A2ADF979F128f9e8a93df938690918c09B@"><ecblank.gif></span></td></tr>
<tr valign="top"><td width="109" valign="middle"><span id="gmail-m_-1994439752551623340cid:1__=09BB0A2ADF979F128f9e8a93df938690918c09B@"><ecblank.gif></span></td><td width="206" valign="middle"><span id="gmail-m_-1994439752551623340cid:1__=09BB0A2ADF979F128f9e8a93df938690918c09B@"><ecblank.gif></span></td></tr></tbody></table><br>
<p></p></div>
______________________________<wbr>_________________<br>swift-corelibs-dev mailing list<br><a href="mailto:swift-corelibs-dev@swift.org" target="_blank">swift-corelibs-dev@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-corelibs-dev" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>corelibs-dev</a><br></div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>
swift-corelibs-dev mailing list<br>
<a href="mailto:swift-corelibs-dev@swift.org">swift-corelibs-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-corelibs-dev" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>corelibs-dev</a><br>
<br></blockquote></div><br></div></div>