Re: How to test a DUB-based library during development?

2018-02-01 Thread Jacob Carlborg via Digitalmars-d-learn

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


Re: How to test a DUB-based library during development?

2018-02-01 Thread DanielG via Digitalmars-d-learn

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.



Re: How to test a DUB-based library during development?

2018-01-30 Thread Joel via Digitalmars-d-learn
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"
}
}
```


Re: How to test a DUB-based library during development?

2018-01-11 Thread jmh530 via Digitalmars-d-learn

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.


Re: How to test a DUB-based library during development?

2018-01-11 Thread DanielG via Digitalmars-d-learn

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 :)


Re: How to test a DUB-based library during development?

2018-01-11 Thread Guillaume Piolat via Digitalmars-d-learn

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


Re: How to test a DUB-based library during development?

2018-01-11 Thread DanielG via Digitalmars-d-learn

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.


Re: How to test a DUB-based library during development?

2018-01-11 Thread Guillaume Piolat via Digitalmars-d-learn

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.



How to test a DUB-based library during development?

2018-01-11 Thread DanielG via Digitalmars-d-learn
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.