Hello,
I have to agree that binary packages In the current form are not very
useful, at least to us. We have played with an idea of having sqlite (C + a
Go wrapper on top) wrapped up into a binary package, so we can continue to
build multiple platforms from a single build machine. As result of
investigation, that deemed to have more hassle than to have all platforms
built separately even with pains of CGO involved.
IMHO, precompiled (pre-built) libraries are nice to have, be that
"platform-dependent binary package" or some platform-agnostic jar file. I
think a success of Java as a platform in no small part could be attributed
to the fact that jar's are so easy to create, distribute and use (minus
obvious dependency hell that we all have to go through periodically).
So far what I can think of
- There are places that cannot distribute a library in source code
format, but would like to distribute a library.
- Pre-built packages can be used to reduce build time (not sure how
important this is with 1.10+ cache)
- Distribution of signed packages? I think it is not easy thing to do
with "just" a source code, unless it comes in a bundled form like a signed
zip file...
Thinking a bit about "richness of meta-info" vs "cannot distribute source
code" and how Java and .NET are doing this... Would replacement of "pure"
compiled-and-ready-to-be-linked library packaging with just compiled and
compressed AST (probably lightly optimized) be a better solution?
This would give
1. a rich (full?) meta info for optimization
2. a way to distribute code without source code for people who have to
do it that way.
3. a bit of platform independence if all of suffixed files
("*_windows.go" , "*_linux.go" etc) are parsed in.
I think it would also give some Go version independence, covering cases
when library was built with older tools, but needs to be assembled with a
newer Go distribution. This might work if...
1. AST is a version independent (sorry, I don't know if it is),
2. AST is platform-agnostic
3. has a forward compatible format or tools reading it are easy to make
backward-compatible
I am probably missing something obvious here (I don't think I am the first
one to think about it, and I am in no way a language expert), but wanted to
share this idea.
Thanks,
Andrey
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
