## digitalmars.D.learn - How do I use libraries manually?

• Murilo (2/2) Feb 05 2019 Can anyone teach me how to download and use a library manually
• H. S. Teoh (74/76) Feb 05 2019 1) Locate the source code. There should be a link from the
• Murilo (4/4) Feb 05 2019 On Tuesday, 5 February 2019 at 19:46:32 UTC, H. S. Teoh wrote:
• H. S. Teoh (23/26) Feb 05 2019 That only works up to a certain point, though. Past a certain level of
• Atila Neves (10/15) Feb 06 2019 That doesn't work in the aggregate.
Murilo <murilomiranda92 hotmail.com> writes:
Can anyone teach me how to download and use a library manually
without having to use DUB?

Feb 05 2019
"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 05, 2019 at 07:06:24PM +0000, Murilo via Digitalmars-d-learn wrote:
Can anyone teach me how to download and use a library manually without
having to use DUB?

1) Locate the source code. There should be a link from the
code.dlang.org page of the library, usually pointing to github.com or
some similar public repo hosting service, or pointing to a .zip or a

<download URL> should create the source directory.  If it's a zip
yourself.

3) Identify the import directory (directories).  For simplicity, Let's
if you're on Windows, C:\path\to\somelibrary\).  If the library is a
DUB package, the code should usually be under "source", i.e.,
/path/to/somelibrary/source or C:\path\to\somelibrary\source. For
complex libraries, there may be more than one such path that you'll
need.

4) Repeat the above step for all dependencies of the library.

git clone http://github.com/somelibrary.git /path/to/somelibrary
git clone http://github.com/anotherlibrary.git /path/to/anotherlibrary

5) Once you've identified all needed import paths, add the import
directories to your dmd command line with -I, one for each import
directory. Using the above example, you'll need something like this:

dmd -I/path/to/somelibrary/source ...

Or, if there's more than one import directory:

dmd -I/path/to/somelibrary/source -I/path/to/anotherlibrary/source ...

6) Add -i to your dmd command line so that it will automatically compile
any imports that you use. This requires a pretty up-to-date version
of dmd.

If this fails, you'll have to manually compile each library and its
library, then finally your program.  You'll probably need to specify
-lib for most of your library dependencies so that dmd produces .so
or .a (or .lib) files that you'll need. You may need separate
compilation if the library is too big to compile all at once.

When linking the library, you'll need to specify any dependent
library .so or .a (.lib) files.

For example, let's say somelibrary depends on anotherlibrary.  For
simplicity, let's assume all their sources lie in the respective
source subdirectory. So you have:

/path/to/somelibrary/source/*.d
/path/to/anotherlibrary/source/*.d

So the first step is to compile anotherlibrary (because somelibrary
depends on it, and may not compile if it's anotherlibrary isn't compiled
first), then compile the rest.

cd /path/to/anotherlibrary
dmd -lib -o libanotherlibrary.a -Isource source/*.d

cd /path/to/somelibrary
dmd -lib -o somelibrary.a -Isource -I/path/to/anotherlibrary/source \
source/*.d /path/to/anotherlibrary/libanotherlibrary.a

cd /path/to/myprogram
dmd -o myprogram -Isource -I/path/to/anotherlibrary/source \
-I/path/to/somelibrary/source source/*.d \
/path/to/anotherlibrary/libanotherlibrary.a \
/path/to/somelibrary/libsomelibrary.a

You'll probably want to put these commands in a shell script / batch
file, since the commands can get pretty long and complicated and
error-prone, and you really don't want to have to retype everything by
hand just to fix a small typo in the middle.  Or put this in a makefile
or build script of your build system of choice.

Note that for each step, you may need additional flags to dmd to compile
a dependency; consult the dub.sdl / dub.json file to find any that might
be necessary.

Welcome to the world of manual compilation. :-D  (This is where you
start to really appreciate things like Adam Ruppe's single-file library
modules, where you can just copy the file into your source tree and
include it in your dmd command line without needing to go through the
above baroque dance.)

T

--
Without geometry, life would be pointless. -- VS

Feb 05 2019
Murilo <murilomiranda92 hotmail.com> writes:
On Tuesday, 5 February 2019 at 19:46:32 UTC, H. S. Teoh wrote:

Thank you very much, I will try what you just explained. And yes
I would really appreciate it if people would make single file
libraries that I can just import as if it were any other .d file.

Feb 05 2019
"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 05, 2019 at 08:39:50PM +0000, Murilo via Digitalmars-d-learn wrote:
[...]
Thank you very much, I will try what you just explained. And yes I
would really appreciate it if people would make single file libraries
that I can just import as if it were any other .d file.

That only works up to a certain point, though.  Past a certain level of
complexity, you have no choice but to split your code up into multiple
files. Otherwise it becomes a maintenance nightmare, not to mention
having the high probability of unwanted coupling between pieces of code
that really should be separated from each other, which usually leads to
code smells and hard-to-find bugs.

Nevertheless, IMO the best libraries are those where you can just unzip
the source files into a subdirectory in your workspace, add a few -I's,
and they will Just Work(tm).  Overly-heavyweight libraries or libraries
with too many recursive dependencies are not only a pain to work with
outside an automatic dependency system like dub, they also have a high
tendency to instability over time (i.e. after 5 years nothing compiles
anymore because one or more dependencies have broken behind your back
and/or the earlier version(s) of the code that used to work no longer
exist / cannot be easily found again).  More and more, I'm finding that
copying the darned code into your source tree directly, rather than have
network dependencies that are here today and may suddenly cease existing
tomorrow with no warning, is the key to code longevity.

T

--
Obviously, some things aren't very obvious.

Feb 05 2019
Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 5 February 2019 at 20:39:50 UTC, Murilo wrote:
On Tuesday, 5 February 2019 at 19:46:32 UTC, H. S. Teoh wrote:

Thank you very much, I will try what you just explained. And
yes I would really appreciate it if people would make single
file libraries that I can just import as if it were any other
.d file.

That doesn't work in the aggregate.

Any non-trivial library will need to be split up into packages
and modules. There might be tasks to be performed before or after
the build. There might be different build configurations. There
might be external C library dependencies. The library might have
dependencies of its own, so the possible complications are
recursive.

Just use dub, it's easier. I don't think there's any good reason
to not use it.

Feb 06 2019