www.digitalmars.com         C & C++   DMDScript  

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

reply 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
parent reply "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
   tarball that you can download.

2) Download the source code.  If it's from github.com, `git clone
   <download URL>` should create the source directory.  If it's a zip
   file or a tarball, you'll need to download and uncompress it
   yourself.

3) Identify the import directory (directories).  For simplicity, Let's
   assume you placed the downloaded sources in /path/to/somelibrary/ (or
   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
   dependencies.  Start with the dependencies first, then the dependent
   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
parent reply 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
next sibling parent "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
prev sibling parent 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