www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Co-developing application and library

reply Russel Winder <russel winder.org.uk> writes:
Dub seems to have the inbuilt assumption that libraries are dependencies th=
at
do not change except via a formal release when you developing an applicatio=
n.
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 doin=
g
this, I haven't been able to infer one to date. But I am a beginner at Dub.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Jan 05 2019
next sibling parent Alex <sascha.orlov gmail.com> writes:
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
Jan 05 2019
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Jan 05 2019
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
Jan 05 2019
next sibling parent Mike Parker <aldacron gmail.com> writes:
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"
Jan 05 2019
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Jan 07 2019
prev sibling next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Sat, 05 Jan 2019 13:01:24 +0000, 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:

---

name "myproject"
targetType "none"

dependency "myproject:lib" version="*"
dependency "myproject:exe" version="*"

subPackage "./lib"
subPackage "./exe"
---

---

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.
Jan 05 2019
parent Neia Neutuladh <neia ikeran.org> writes:
On Sat, 05 Jan 2019 17:44:27 +0000, 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:

---

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:

---

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.
Jan 05 2019
prev sibling parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
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.
Jan 06 2019