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
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. # 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
Feb 05
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
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
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