How do I install a library?

[H. S. Teoh]

On Thu, Nov 08, 2018 at 11:51:39PM +0000, bachmeier via Digitalmars-d-learn wrote:
> On Thursday, 8 November 2018 at 23:43:38 UTC, Murilo wrote:
> 
> > It finally worked, but I can't just compile it normally, I have to
> > use dub run, I wish it were something simple that I just download
> > into the folder and then use an import statement and then compile it
> > like any other program. I wish it were as simple as using std.stdio
> > for example.
> 
> Unfortunately your stuck with Dub if you want to use D. It's an awful
> experience compared to Python and other scripting languages, so I
> understand what you're saying, but most people around here think Dub
> is the way to go.

It's not true that you're stuck with dub.  And I'm not among the people
who think dub is the way to go (though it's true that that's a minority
opinion around here).  Where I have a choice, my own D projects do not
use dub.

I have one project that uses dub because it's based on vibe.d, but I
mostly avoid needing to use dub by creating an empty dub project in a
subdirectory whose sole purpose is to declare a dependency on vibe.d.
Then I build that once with dub, and outside in my real project I just
link directly to the produced artifacts. (The exact path(s) to the dub
products can be extracted from the output of `dub -v`. This can probably
be automated and translated into your build system of choice, though I
haven't quite gone that far yet.)  Then I don't need to use dub except
when upgrading the dub-dependent library.

I find dub almost completely unusable for normal development, because:

(1) it requires network access,

(2) it's dog-slow compared to how fast the actual D compiler runs (it
tries to do dependency updating every single time it runs, even when all
you've done is to change 1 line in your code),

(3) it either does not support incremental builds, or else is so bad at
doing it that it takes about just as long as a full build from scratch;

(4) it's not configurable enough to meet my build needs -- e.g., it's
completely unable to handle my current Android project that involves
compiling Java code, D code, GLSL code, and cross-compiling / linking /
building an APK, plus compile and link an X11 test driver on the host
PC, which involves invoking a different (non-cross) compiler with
different libraries and a different set of source files -- dub's build
spec simply isn't capable of expressing the level of configurability
required to do all of this;

(5) it imposes a source tree hierarchy that conflicts with what I need
(Android SDK's APK tools expect a particular directory structure that
does not fit into dub's model).


While I appreciate the amount of effort it took to develop and deploy
dub, I am sorry to say that it falls far short of my expectations and I
can't see myself using it in any meaningful sense in the foreseeable
future.  Using it as a dependency puller for vibe.d is about as far as I
will go, unfortunately.

Many of dub's limitations, AFAICT, are inherent to its design and
architecture, so I don't see any easy way to fix these problems either,
short of rewriting it from scratch (and I have no inclination to take on
something that big at this time).

Atila Neves has also created his own D-based build system that
reportedly is much superior to dub.  You might want to look into that as
well.


T

-- 
INTEL = Only half of "intelligence".