search

AnarchyTools / atbuild

The Anarchy Tools build tool
Apache License 2.0
6 stars 1 forks source link

Support static linking of the swift library for executables #64

Open drewcrawford opened 8 years ago

drewcrawford commented 8 years ago

Our executables break a lot in-between snapshots. This is bad.

To fix this, we should support statically linking executables, and it should maybe even be on by default.

I have some partial work on this on the static_support branch, however, upstream bug https://bugs.swift.org/browse/SR-730 affects further progress on Linux.

It would be possible for us to not use swiftc as a linker (and work around that bug) but swiftc is the preferred linker according to upstream, so this may not be desireable. Also that might break things that assume swiftc is our linker now.

I will wait a bit to see what upstream plans to do on this.

drewcrawford commented 8 years ago

@owensd @dunkelstern

Considering upstream's delays, I wanted to take your temperature on a "dangerous idea".

What if I maintain the static lib stuff out-of-tree and we all run "Anarchy-flavored Swift"?

We pretty much already do this for Linux (my Linux images include various out-of-tree fixes) but I have not yet tooled up to do this on OSX.

Would like to take your temperature on such a move before making it a build dependency.

owensd commented 8 years ago

Yeah... I'm not terribly convinced this is a good plan. At some point, if all of our stuff is just a fork of what Apple is doing, what's the point? I'd rather just work on my own language then. ;)

I completely get the desire, and I'm ok with doing this approach:

  1. Maintain the ability to build Anarchy Tools with Swift proper, but
  2. Publish the bits for Anarchy Tools built with your static lib modifications.

I don't know if that puts too much burden on your plate to support that though.

Thoughts?

drewcrawford commented 8 years ago

Oh I think we need to continue support Swift proper. (In fact, we recently added support for building Swift 2 projects, which will never get this feature).

I'm just saying, practically, maybe our feature development should not be bound by upstream's timetable. Maybe we need to ship this feature and support it when building with "our" Swift.

owensd commented 8 years ago

I think we are saying the same thing.

If you want to use your forked version of Swift on your machine(s) and you want to use that on the CI machines, that seems ok. It's still a little risky, but overall, should be ok as long as the fork is kept up-to-date with the snapshots.

Also, if you want to put that forked version under Anarchy Tools, which I think is both reasonable and expected, then I'm all for that as well.

However, I don't really want to use the forked version on my box (at least, I'm not convinced enough that I need it... yet). So if I can still hack on Anarchy Tools with the latest snapshot (I'm on OSX only), then 👍.

drewcrawford commented 8 years ago

You should still be able to hack with the latest snapshot, you just won't be able to build a static binary.

It's an interesting question whether the swift builds should be hosted under the AT banner as my Linux stuff contains patches that we don't strictly-speaking use. I really only have time to maintain one tree and it contains whatever fixes my projects require, usually of the form "Make Linux more like Darwin".