Open jemc opened 6 years ago
I'm filing this ticket to make sure my understanding is correct, discover what work is required to push this forward, and start working toward this end, if we can agree that we're making the right tradeoffs as I described above. My end-goal is to have Pony support creating static binaries as easily and as portably as languages like Go do.
@SeanTAllen Maybe some Wallaroo Labs folks might want to collaborate on this as well, since it should make it easier for their end-users to install and use Wallaroo?
It looks like this is at least partially complete with #1058, but it's currently an optional process that takes extra work on the user-developer side to make it happen, rather than something that's available by default.
@jemc sounds interesting. definitely good for us long term but, not something we'd be able to do much on for at least a couple months.
It looks like the next logical step is make it so that the libponyrt
bitcode gets built for ponyc releases, and bundled with the distribution of ponyc
binaries, just like we bundle the pony code for the standard libraries.
Note that this means that our ponyc
releases would need to be to built with clang
so that they could build the bitcode.
We can do this fairly easily on linux and macos, but windows will take a little longer. We don't have to do it all at once.
I'm opening this ticket to capture some important discussion from another ticket, which got dropped when that ticket was closed: https://github.com/ponylang/ponyc/issues/1331#issuecomment-256494016
The gist of the discussion, as I understand it, is that we should try to distribute LLVM bitcode for
libponyrt
as part of aponyc
installation.When doing
release
builds of a pony program, we'd link against the LLVM bitcode forlibponyrt
instead of the shared library, and we'd enable whole-program-optimization (WPO). This would result in better-optimized pony program binaries. The binaries would also be independent oflibponyrt
, and could thus be distributed more easily to end-users of Pony-language programs, without those end-users needing to have their own Pony-language installation - similar to how Go static binaries are independent of any Go-language dependencies for the end user.The disadvantages are:
libponyrt
inside of them will be larger than those that link to it dynamically.ponyc
will be more tightly coupled toclang
, and it's not clear to me that we can still continue to supportgcc
as a compiler.clang
in the same installation (and even when they do come in separate packages, both should be equally easy to obtain for your system). I've come around to believing that this is not a significant burden on the user-developer, and will significantly reduce the burden on maintenance of the language itself - I seem to recall we've had a lot of tickets come from supporting old or new or differently-configured versions of GCC.release
builds of pony programs will be slower, as it will be analyzing more LLVM bitcode, and making more optimizations.debug
builds nice and fast, so that development iterations can still happen as quickly as possible. Makingrelease
builds of pony programs will be slower, but the resulting programs will be faster - which seems like the right tradeoff to be making forrelease
builds.