[swift-build-dev] [Review] SE-0038 Package Manager C Language Target Support

[Daniel Dunbar]

Hi Chris,

On Thu, Feb 18, 2016 at 1:25 PM, Chris Bailey via swift-build-dev <
swift-build-dev at swift.org> wrote:

> Hi Rick:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>

We have three parallel features that all target this area, and I think that
eventually they will converge:

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.

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).

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:

https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160104/000154.html

 - Daniel


>
> Thanks,
>
> Chris
>
>
>
>
> From:        Rick Ballard via swift-build-dev <swift-build-dev at swift.org>
> To:        swift-evolution-announce at swift.org
> Cc:        swift-evolution <swift-evolution at swift.org>,
> swift-build-dev at swift.org
> Date:        17/02/2016 02:12
> Subject:        [swift-build-dev] [Review] SE-0038 Package Manager C
> Language        Target Support
> Sent by:        swift-build-dev-bounces at swift.org
> ------------------------------
>
>
>
> Hello Swift community,
>
> 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:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
>                 https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> 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:
>
>                 * What is your evaluation of the proposal?
>                 * Is the problem being addressed significant enough to
> warrant a change to the Swift Package Manager?
>                 * Does this proposal fit well with the feel and direction
> of the Swift Package Manager?
>                 * If you have you used other package managers with a
> similar feature, how do you feel that this proposal compares to those?
>                 * How much effort did you put into your review? A glance,
> a quick reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
>                 - Rick
>                   Review Manager
>
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
>
>
>
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160218/7495e8c8/attachment.html>