On Friday, 2 February 2018 at 14:04:09 UTC, Russel Winder wrote:
On Fri, 2018-02-02 at 10:03 +0000, Atila Neves via
Digitalmars-d wrote:
[…]
Whether it's .a or .so depends on the dependent package being
`staticLibrary` or `dynamicLibrary`. It's possible for a
package to be both if it has a configuration for each.
I think that is one of my points, the package source downloaded
from the Dub repository should not be determining whether a .a
or ,so is produced, it should be determined by the receiver of
the downloaded package.
Personally I don't even see the point - just link all the .o
files. In a traditional build system static libraries might be
useful to specify that multiple targets link to this
particular binary blob. With dub there's only ever one binary
anyway.
But a static library is just a collection of .o files so I
think it fits with "link all the .o together".
Not quite. There's an extra step and when linking with a static
library unused symbols are thrown away by default. That hid a dmd
bug in 2.078.0 that only manifests when linking with the object
files themselves.
It is clear that there is a move in the Go, Rust, D communities
to rejecting the concept of shared library, and that 100MB
executables are acceptable.
On a desktop, 100MB executables are, at least to me. Shared
libraries aren't going to magically make 100MB executables
disappear, it depends on how much code is actually shared.
And at this point in time I think shared libraries are mostly
a mistake. The only time I use them is when I have to, as in
when developing Python extensions.
The single biggest argument for shared libraries in D is GtkD.
Linking an executable with a static GtkD library takes ages,
and when developing you do a lot of linking. Fast turnaround,
and thus reasonable development times, requires use of a shared
library for GtkD.
That's a fair point.
Atila
