Can anyone teach me how to download and use a library manually without having to use DUB?

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.

	# Example
	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

	# Assuming the preceding was successful
	cd /path/to/somelibrary
	dmd -lib -o somelibrary.a -Isource -I/path/to/anotherlibrary/source \
		source/*.d /path/to/anotherlibrary/libanotherlibrary.a

	# Finally, compile your own program
	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

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.

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.

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.