Re: Co-developing application and library
On 2019-01-05 16:17, Mike Parker wrote: What I do is use `dub add-local /path/to/lib 0.0.1` and use that explicit version for development. That way, whatever repository branch is currently active in that directory becomes version 0.0.1 and I can make use of any changes. The problem with that is that will affect all projects on the machine using that dependency. I think the approach mentioned by Alex is the best. -- /Jacob Carlborg
Re: Co-developing application and library
On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote: Dub seems to have the inbuilt assumption that libraries are dependencies that do not change except via a formal release when you developing an application. Clearly there is the workflow where you want to amend the library but not release as a part of developing an application. Does Dub have a way of doing this, I haven't been able to infer one to date. But I am a beginner at Dub. I use submoduals in git and then subpackage in dub. That doesn't help with packages I don't maintain but want to contribute back to because I don't submodual those in. I actually wish submoduals got more attention and was the expected way to manage dependencies.
Re: Co-developing application and library
On Sat, 05 Jan 2019 17:44:27 +, Neia Neutuladh wrote:
> 2. Different build configurations. The same source code has two
> different build targets; the executable doesn't depend on the library.
> Or, with enough bludgeoning, you can make the executable depend on the
> library.
Hit 'send' too soon.
The build configuration way would be:
---
# dub.sdl
configuration "exe" {
targetType "executable"
}
configuration "lib" {
targetType "staticLibrary"
excludedSourceFiles "src/cli/*"
}
---
Then you'd build with:
dub build --config=lib
dub build --config=exe
To make this version of things yield an executable depending on a library,
you'd use something like:
---
# dub.sdl
configuration "exe" {
targetType "executable"
excludedSourceFiles "src/lib/*"
importPaths "src/lib"
libs "-L." "-L-l:libmyproject.so"
}
configuration "lib" {
targetType "sharedLibrary"
excludedSourceFiles "src/cli/*"
}
---
The one advantage of this is being able to use shared libraries. It's
awkward.
Re: Co-developing application and library
On Sat, 05 Jan 2019 13:01:24 +, Russel Winder wrote: > Dub seems to have the inbuilt assumption that libraries are dependencies > that do not change except via a formal release when you developing an > application. > Clearly there is the workflow where you want to amend the library but > not release as a part of developing an application. Does Dub have a way > of doing this, I haven't been able to infer one to date. But I am a > beginner at Dub. There are a few ways to do this: 1. Path dependency, as Alex mentioned. 2. Different build configurations. The same source code has two different build targets; the executable doesn't depend on the library. Or, with enough bludgeoning, you can make the executable depend on the library. 3. Subprojects. 4. dub add-local on the library, as Mike Parker mentioned. I wouldn't depend on ~master because (a) that won't change until you commit stuff and (b) it might require also running dub upgrade to get the new source code. The subproject way of doing things: --- # dub.sdl name "myproject" targetType "none" # So we build the child projects dependency "myproject:lib" version="*" dependency "myproject:exe" version="*" # To define the child projects subPackage "./lib" subPackage "./exe" --- --- # exe/dub.sdl name "exe" dependency "myproject:lib" version="*" targetType "executable" --- This will intuit a project structure like: dub.sdl exe/ dub.sdl src/ lib/ dub.sdl src/ But if you prefer, you can modify that with "sourcePaths" in the subpackage dub.sdls.
Re: Co-developing application and library
On Saturday, 5 January 2019 at 15:17:28 UTC, Mike Parker wrote: On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote: Dub seems to have the inbuilt assumption that libraries are dependencies that do not change except via a formal release when you developing an application. Clearly there is the workflow where you want to amend the library but not release as a part of developing an application. Does Dub have a way of doing this, I haven't been able to infer one to date. But I am a beginner at Dub. What I do is use `dub add-local /path/to/lib 0.0.1` and use that explicit version for development. That way, whatever repository branch is currently active in that directory becomes version 0.0.1 and I can make use of any changes. Alternatively, I sometimes use the path to the library rather than a version specification in the package recipe. With the SDLang format: dependency mylib path="path/to/lib"
Re: Co-developing application and library
On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote: Dub seems to have the inbuilt assumption that libraries are dependencies that do not change except via a formal release when you developing an application. Clearly there is the workflow where you want to amend the library but not release as a part of developing an application. Does Dub have a way of doing this, I haven't been able to infer one to date. But I am a beginner at Dub. What I do is use `dub add-local /path/to/lib 0.0.1` and use that explicit version for development. That way, whatever repository branch is currently active in that directory becomes version 0.0.1 and I can make use of any changes.
Re: Co-developing application and library
On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote: Dub seems to have the inbuilt assumption that libraries are dependencies that do not change except via a formal release when you developing an application. Clearly there is the workflow where you want to amend the library but not release as a part of developing an application. Does Dub have a way of doing this, I haven't been able to infer one to date. But I am a beginner at Dub. you can depend on ~master as a version, I'm not sure if you have to tell it to refresh what is has.
Re: Co-developing application and library
On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote:
Dub seems to have the inbuilt assumption that libraries are
dependencies that do not change except via a formal release
when you developing an application. Clearly there is the
workflow where you want to amend the library but not release as
a part of developing an application. Does Dub have a way of
doing this, I haven't been able to infer one to date. But I am
a beginner at Dub.
I solved this by adding
"libraryName" : {"path" : "relative/path/to/library"}
to the dependency block
Co-developing application and library
Dub seems to have the inbuilt assumption that libraries are dependencies that do not change except via a formal release when you developing an application. Clearly there is the workflow where you want to amend the library but not release as a part of developing an application. Does Dub have a way of doing this, I haven't been able to infer one to date. But I am a beginner at Dub. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
