www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How to test a DUB-based library during development?

reply DanielG <simpletangent gmail.com> writes:
I want to create a library and eventually publish it via the DUB 
registry.

Is there a simple example that shows how to test the library 
during development, before publishing (ie, before being able to 
add it as a dependency to another project)?

I guess I'm just asking, what's the convention here? Do I create 
a separate project and then add my not-yet-published library via 
'dub add-local'? Put everything in a unittest in the library 
itself? etc etc.
Jan 11 2018
next sibling parent reply Guillaume Piolat <notthat email.com> writes:
On Thursday, 11 January 2018 at 12:27:27 UTC, DanielG wrote:
 Is there a simple example that shows how to test the library 
 during development, before publishing (ie, before being able to 
 add it as a dependency to another project)?

 I guess I'm just asking, what's the convention here? Do I 
 create a separate project and then add my not-yet-published 
 library via 'dub add-local'? Put everything in a unittest in 
 the library itself? etc etc.
You may have some unittest blocks in your source files, and then type: $ dub test If you want to add examples, some do it either A. with a separate dub.json/dub.sdl To keep your example up-to-date with master you should use path-based dependencies. See https://github.com/vibe-d/vibe.d/tree/master/examples for examples examples. This is the closest to "standard" you'll get. But if the examples are too large and numerous some libraries also keep them in another repositery, in such case you will need to use tags. B. with a DUB configuration C. with a DUB sub-package IMHO you should rather do A rather than C rather than B.
Jan 11 2018
next sibling parent reply DanielG <simpletangent gmail.com> writes:
Thank you very much, very helpful!

I'm currently attempting the (A) suggestion, but find that dub 
isn't fixing up the relative path to one of the parent's 
prerequisite libraries.

In the parent:

    "libs-windows-x86-dmd": ["./lib/32/dmd/SomeLibrary"]

This causes a warning when building the nested example, because 
it's not adjusting the path:

    "Warning 2: File Not Found .\lib\32\dmd\SomeLibrary.lib"

If I manually override "libs-windows-x86-dmd" in the example's 
dub.json, it links despite the error, but if possible I would 
like users of my library to not have to concern themselves with 
linkage issues.
Jan 11 2018
parent reply Guillaume Piolat <notthat email.com> writes:
On Thursday, 11 January 2018 at 14:22:50 UTC, DanielG wrote:
 If I manually override "libs-windows-x86-dmd" in the example's 
 dub.json, it links despite the error, but if possible I would 
 like users of my library to not have to concern themselves with 
 linkage issues.
vibe.d seems to do it successfully: https://github.com/vibe-d/vibe.d/blob/master/tls/dub.sdl#L18
Jan 11 2018
parent reply DanielG <simpletangent gmail.com> writes:
Ah, thank you! I replaced:

     "libs-windows-x86-dmd"

with:

     "sourceFiles-windows-x86-dmd" (and added a .lib suffix)


and now everything works as expected.

I see now that I was using "libs" improperly. It seems more for 
system-wide libraries / things in the library search path, not to 
be used for individual .lib files.

Thanks again, you saved me many hours this morning :)
Jan 11 2018
parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 11 January 2018 at 14:59:18 UTC, DanielG wrote:
 Ah, thank you! I replaced:

     "libs-windows-x86-dmd"

 with:

     "sourceFiles-windows-x86-dmd" (and added a .lib suffix)


 and now everything works as expected.

 I see now that I was using "libs" improperly. It seems more for 
 system-wide libraries / things in the library search path, not 
 to be used for individual .lib files.

 Thanks again, you saved me many hours this morning :)
I get mixed up with that too.
Jan 11 2018
prev sibling parent reply Joel <joelcnz gmail.com> writes:
On Thursday, 11 January 2018 at 12:36:22 UTC, Guillaume Piolat 
wrote:
 On Thursday, 11 January 2018 at 12:27:27 UTC, DanielG wrote:
[snip]
 You may have some unittest blocks in your source files, and 
 then type:

     $ dub test
[snip] When I try 'dub test' I get errors like 'Source file '/Users/joelchristensen/jpro/dpro2/JMiscLib/source/jmisc/base.d' not found in any import path.' Here's the dub.json file I'm using: ``` { "name": "timelog", "targetType": "executable", "description": "A Joel D program. A D Diary program.", "copyright": "Copyright © 2018, joelcnz - note: I don't understand this", "authors": ["Joel Ezra Christensen"], "DFLAGS": ["g"], "sourcePaths" : ["source", "../JTaskLib/source", "../JMiscLib/source" ], "dependencies": { "dlangui": "~>0.9.56" } } ```
Jan 30 2018
parent DanielG <simpletangent gmail.com> writes:
On Wednesday, 31 January 2018 at 04:57:14 UTC, Joel wrote:
 When I try 'dub test' I get errors like 'Source file 
 '/Users/joelchristensen/jpro/dpro2/JMiscLib/source/jmisc/base.d' not found in
any import path.'
You might want to ask this in a new thread so more people see it.
Feb 01 2018
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2018-01-11 13:27, DanielG wrote:
 I want to create a library and eventually publish it via the DUB registry.
 
 Is there a simple example that shows how to test the library during 
 development, before publishing (ie, before being able to add it as a 
 dependency to another project)?
 
 I guess I'm just asking, what's the convention here? Do I create a 
 separate project and then add my not-yet-published library via 'dub 
 add-local'? Put everything in a unittest in the library itself? etc etc.
You should have unit tests to the library. You can also create a new project and add the library as a dependency. Instead of using "dub add-local" I recommend specifying a path instead of the version for the dependency [1] : dependency "libfoo" path="/path/to/libfoo" [1] http://code.dlang.org/package-format?lang=sdl#version-specs -- /Jacob Carlborg
Feb 01 2018