<div dir="ltr">Hi Chris,<div><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 18, 2016 at 1:25 PM, Chris Bailey via swift-build-dev <span dir="ltr"><<a href="mailto:swift-build-dev@swift.org" target="_blank">swift-build-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><font size="2" face="sans-serif">Hi Rick:</font>
<br>
<br><font size="2" face="sans-serif">Thanks for putting this proposal together
- having the ability to build and link to C dependencies is going to be
a huge step forward and this very much looks like a step in the right direction.</font>
<br>
<br><font size="2" face="sans-serif">I know there's been some discussion
about being able to invoke custom build targets and/or link to local dependencies.
I agree that we don't want to pre-design the entire solution but iterate
in the right direction and get feedback as we go. One thing we can do is
look at some of the challenges and solutions from other languages.</font>
<br>
<br><font size="2" face="sans-serif">If we look at Node.js/NPM, as the most
used language package manager, it highlights the high usage of native modules.
Most native modules have a dependency on "nan" which has >6.5M
downloads a month and approaching 1000 dependent modules.</font>
<br>
<br><font size="2" face="sans-serif">As an example, one of those dependents
is "zmq" (30K+ downloads/month) which provides Node.js bindings
for ZeroMQ. This provides a Node.js wrapper around the zeromq library (installable
via homebrew, apt-get etc). The NPM approach is that at install/build time,
the binding.gyp file can be configured to check for the presence of the
library, and to add the necessary include and link flags.</font>
<br>
<br><font size="2" face="sans-serif">I know that supporting that kind of
scenario is outside of the scope of this proposal - is it however a direction
we're headed to?</font>
<br></blockquote><div><br></div><div>We have three parallel features that all target this area, and I think that eventually they will converge:</div><div><br></div><div>1. Our existing system module maps feature is designed to allow integrating installed software with the package ecosystem. I am sure it will grow more "conditional" features over time.</div><div><br></div><div>2. For projects which have a straightforward enough build process to be fully described via our built in support (possibly using manifest override features not yet designed), then I would like for them to be able to be described as packages following this proposal (e.g., maybe there could be a package which describes ZeroMQ that we could build it fully inside the ecosystem).</div><div><br></div><div>3. There will be other projects outside that scope, but which we want to also allow to participate in the ecosystem. For them, I suspect the best solution is an alternate "adaptor" mechanism for integrating them into the ecosystem. Some of my thoughts on that are in this thread:</div><div> <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160104/000154.html">https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160104/000154.html</a></div><div><br></div><div> - Daniel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br><font size="2" face="sans-serif">Thanks,</font>
<br>
<br><font size="2" face="sans-serif">Chris<br>
</font>
<br>
<br>
<br>
<br><font size="1" color="#5f5f5f" face="sans-serif">From:
</font><font size="1" face="sans-serif">Rick Ballard via swift-build-dev
<<a href="mailto:swift-build-dev@swift.org" target="_blank">swift-build-dev@swift.org</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">To:
</font><font size="1" face="sans-serif"><a href="mailto:swift-evolution-announce@swift.org" target="_blank">swift-evolution-announce@swift.org</a></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Cc:
</font><font size="1" face="sans-serif">swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>,
<a href="mailto:swift-build-dev@swift.org" target="_blank">swift-build-dev@swift.org</a></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Date:
</font><font size="1" face="sans-serif">17/02/2016 02:12</font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Subject:
</font><font size="1" face="sans-serif">[swift-build-dev]
[Review] SE-0038 Package Manager C Language Target
Support</font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Sent by:
</font><font size="1" face="sans-serif"><a href="mailto:swift-build-dev-bounces@swift.org" target="_blank">swift-build-dev-bounces@swift.org</a></font>
<br>
<hr noshade><div class=""><div class="h5">
<br>
<br>
<br><tt><font size="2">Hello Swift community,<br>
<br>
A review of “Package Manager C Language Target Support” for the Swift
Package Manager begins now and runs through Monday, February 22th. The
proposal is available here:<br>
<br>
</font></tt><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md" target="_blank"><tt><font size="2">https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md</font></tt></a><tt><font size="2"><br>
<br>
Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at<br>
<br>
</font></tt><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank"><tt><font size="2">https://lists.swift.org/mailman/listinfo/swift-evolution</font></tt></a><tt><font size="2"><br>
<br>
or, if you would like to keep your feedback private, directly to the review
manager.<br>
<br>
What goes into a review?<br>
<br>
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction
of Swift. When writing your review, here are some questions you might want
to answer in your review:<br>
<br>
* What is your evaluation of the proposal?<br>
* Is the problem being addressed significant enough to warrant a change
to the Swift Package Manager?<br>
* Does this proposal fit well with the feel and direction of the Swift
Package Manager?<br>
* If you have you used other package managers with a similar feature, how
do you feel that this proposal compares to those?<br>
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?<br>
<br>
More information about the Swift evolution process is available at<br>
<br>
</font></tt><a href="https://github.com/apple/swift-evolution/blob/master/process.md" target="_blank"><tt><font size="2">https://github.com/apple/swift-evolution/blob/master/process.md</font></tt></a><tt><font size="2"><br>
<br>
Thank you,<br>
<br>
- Rick<br>
Review Manager<br>
<br>
_______________________________________________<br>
swift-build-dev mailing list<br>
<a href="mailto:swift-build-dev@swift.org" target="_blank">swift-build-dev@swift.org</a><br>
</font></tt><a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" target="_blank"><tt><font size="2">https://lists.swift.org/mailman/listinfo/swift-build-dev</font></tt></a><tt><font size="2"><br>
</font></tt>
<br>
<br>
</div></div><br>_______________________________________________<br>
swift-build-dev mailing list<br>
<a href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br>
<br></blockquote></div><br></div></div>