[swift-build-dev] C dependencies

Sat Dec 12 17:46:49 CST 2015

> 1. Support a great development experience for building projects from source, where we build everything into the sandbox for that project. We would like to eventually support being able to build more complex dependencies (like external C projects) as part of a package build.
> 2. Leave deployment and installation of packages to system package managers (i.e., someone else).

Okay, this is good information.  The output of the package manager is a .a (or .so, .dylib, Mach-O executable, etc.) and it is your job to install that to a path on your system, or not.  This seems like a good model.  I might suggest updating the README in some way that explains this.

This is actually vaguely analogous to Rust's cargo, so I would suggest looking there for design concepts, as they are quite a bit further ahead of us on this problem.

> If you look at how easy and portable it is to install projects with complex dependencies in ecosystems like Python + virtualenv, that is the kind of environment we want for Swift and eventually for the C family dependencies.

I'm (sadly) intimately familiar.  It is not really all that easy, primarily because of binary hell, as anyone who has googled how to install pycairo can attest.  I really want to do better on this problem than Python does.

Here's a concrete question: how would we advise a hypothetical swiftcairo project to package themselves in the package manager?  Should they:

1.  Call out to a shell script that does `brew install cairo` on OSX, `apt-get install cairo` on Debian, etc.
2.  Print some error telling them to come back when they've installed cairo somewhere on their system.  Good luck, kid
3.  Write a shell script that downloads and builds cairo from source including all its dependencies
4.  Create a tree in the swift package manager like

swiftcairo <-- cairo <-------pixman
                     <-------freetype
                     <-------fontconfig
                     <-------libpng
                     <-------glib
  Where each of these "packages" are mostly a shell script that runs a lot of `curl -O` `tar xf` `configure` `make` etc.
5.  Do we try and second-guess what libpng's autotools want to do?  (Bad, bad, idea.  Build the way libpng decided to build, don't try to guess based on the arrangement of .c files in a folder)
6.  Other ideas?

A vision for the pathological case like Cairo will illuminate the simpler cases.  IMO it would be nice if "depends: swiftcairo" would 'just work', but that may be out of scope.

>  (and if you give me pointers to the full tree I would be interested in checking them out as test cases), this feature may be enough that you could in theory get your Swift package to also build the necessary C libraries (with some adaption work). Stay tuned...

NaOH <https://code.sealedabstract.com/drewcrawford/NaOH> is a good test case.  It's a framework that statically links libsodium.  My current (terrible) workflow is:

1.  Download libsodium-xx.tar.gz <https://github.com/jedisct1/libsodium/releases> from GitHub
2.  ./configure && make
3.  Move binaries + .h around to where Xcode can find them
4.  Check into source control
5.  Build

Would love to automate this and get it building with the package manager.  There's actually been an issue open <https://code.sealedabstract.com/drewcrawford/NaOH/issues/1> since pretty much day 1 to get this working.  That is the problem that motivated me to post.  

> On Dec 12, 2015, at 11:02 AM, Daniel Dunbar <daniel_dunbar at apple.com> wrote:
> 
> I would say that our main goals are two fold:
> 1. Support a great development experience for building projects from source, where we build everything into the sandbox for that project. We would like to eventually support being able to build more complex dependencies (like external C projects) as part of a package build.
> 2. Leave deployment and installation of packages to system package managers (i.e., someone else).
> 
> As a good example of #1, it would be awesome if in the future that even a project like the Swift compiler itself -- with its complicated dependency tree and build process -- could be configured and built with the package manager.
> 
> The goals here are mostly oriented around how do we give the best possible developer experience for constructing source code. I strongly believe that the "container" / "sandbox" model is the right way to go in order to build tools which give reproducible results, allow for easy sharing and deployment, and encourage modular development. If you look at how easy and portable it is to install projects with complex dependencies in ecosystems like Python + virtualenv, that is the kind of environment we want for Swift and eventually for the C family dependencies.
> 
> Goal #2 of trying to stay out of the system package manager business (installing built software) is more out of trying to maintain a clear focus and emphasis than anything else. We already have a ton of work to do on the package manager even within that scope, so it just makes sense for now to leave this problem to existing projects better suited to the task.
> 
> FWIW, I am working on a proposal for our initial support for *building* C family sources as part of Swift packages. Depending on exactly how complicated your dependencies are (and if you give me pointers to the full tree I would be interested in checking them out as test cases), this feature may be enough that you could in theory get your Swift package to also build the necessary C libraries (with some adaption work). Stay tuned...
> 
>> On Dec 12, 2015, at 5:04 AM, Drew Crawford via swift-build-dev <swift-build-dev at swift.org> wrote:
>> 
>> I noticed the README for the package manager seems to take a strong view of source distribution:
>> 
>>> Packages are distributed and consumed as source code, rather than pre-compiled binaries.
>>> Although it requires additional computational resources, this approach guarantees that developers can adopt new features on platforms they support, without being reliant on vendors to supply updated dependencies. This also has the advantage of allowing tools to do things like automated testing and API analysis of package dependencies.
>> 
>> I maintain a lot of Swift software with C dependencies.  For example, I develop Swift frameworks that ship with libsodium statically linked.  AFAIK the new Foundation will have various C dynamic and static dependencies.  Etc.
>> 
>> What is the vision for distributing this software with the package manager?
>> 
>> 1.  Will it barf if the user does not have the C dependencies already installed on their machine?
>>   1a.  What about iOS, where there is no concept of this?  Can I not build iOS libraries using the package manager?
> 
> Yes, it would barf. We are open to improving the reliability of the "system modules" mechanism to be more robust. We do need to support interoperating with installed libraries, and it would be great to make this as smooth as possible.
> 
>> 2.  Are all binary packages forbidden?  Is there any mechanism like homebrew's bottles for distributing software that is arcane to compile?
> 
> We don't have such a mechanism, and as I said the goal of the package manager is to build your project, not distribute it as installable packages. I can imagine adding mechanisms to *help you create* an easily installable product, but I think the actual installation of that product should be left to other tools.
> 
>> 3.  Can I write a script that tries to resolve various C dependencies my project needs to link with?
> 
> Not currently. What exactly are you envisioning here?
> 
>> 4.  Is it a design goal to distribute Foundation via the package manager?
> 
> I'm not sure what you mean. Foundation itself is a special case, it is something we consider part of the Swift corelibs and will ship with the Swift compiler.
> 
> We *would* like to be able to build the Foundation project with the package manager, but there are a lot of things that need to get sorted out before that can happen.
> 
> HTH,
> - Daniel
> 
>> _______________________________________________
>> swift-build-dev mailing list
>> swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-build-dev <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/20151212/448094b6/attachment.html>