digitalmars.D.learn - How to test a DUB-based library during development?
- DanielG (9/9) Jan 11 2018 I want to create a library and eventually publish it via the DUB
- Guillaume Piolat (16/23) Jan 11 2018 You may have some unittest blocks in your source files, and then
- DanielG (13/13) Jan 11 2018 Thank you very much, very helpful!
- Guillaume Piolat (3/7) Jan 11 2018 vibe.d seems to do it successfully:
- Joel (26/30) Jan 30 2018 [snip]
- DanielG (2/4) Feb 01 2018 You might want to ask this in a new thread so more people see it.
- Jacob Carlborg (9/18) Feb 01 2018 You should have unit tests to the library. You can also create a new
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
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
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
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
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
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
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
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
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