www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Dub and compilation

reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
As I understand it, Dub compiles a downloaded dependency into the local
Dub cache. This means you cannot store a debug build and a release
build for multiple architectures and different compilers, at the same
time, and you only get a .a file, no .so file.

Cargo downloads source to the cache but compiles to the project area,
separating debug and release builds. Each project has it's own
compilation of the shared source.

I believe Cargo has this right and Dub has this wrong. So wrong that
SCons, CMake, and Meson have a strong role in the D world. As it
stands, Dub is fine for fetching dependencies and then has no more role
to play in the build of a project. Actually then the Dub command has no
useful role since it may well be better for the build tools to just use
the Dub repository API directly.

Unless I have misunderstood Dub, or someone is fixing it.

--=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=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   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 10 2017
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 11 April 2017 at 05:15:37 UTC, Russel Winder wrote:
 As I understand it, Dub compiles a downloaded dependency into 
 the local Dub cache. This means you cannot store a debug build 
 and a release build for multiple architectures and different 
 compilers, at the same time, and you only get a .a file, no .so 
 file.
DUB downloads the source of dependencies from github and stores it all in the system cache. Each package has its own versioned folder in the cache and, when compiled, is given a .dub subdirectory in the package root. Beneath that is a 'build' directory, with more subdirectories containing the compiled binaries, each directory named according to the build configuration. For example, in my system DUB cache I can find the following tree for my most recent version of DerelictUtil: - derelict-util-3.0.0-alpha.2 -- derelict-util --- .dub ---- build ----- library-debug-windows-x86_64-dmd_2073-1A55853403BAAAABC81F905E0C646FAE ----- library-debug-windows-x86_64-dmd_2073-95AB5FFC7D0B24B49867C17EFB3ABAE2 ----- library-debug-windows-x86-dmd_2073-28A666061AF3118C33673AAFB9F3BFDE You'd have to ask Sönke or someone familiar with the internals what the hash represents, but I suspect it has to do with the project for which the package was compiled. Each of the output directories has a copy of DerelictUtil.lib. It could just as easily be a shared library if the dependency allows that as a configuration.
Apr 10 2017
parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
T24gVHVlLCAyMDE3LTA0LTExIGF0IDA2OjQ1ICswMDAwLCBNaWtlIFBhcmtlciB2aWEgRGlnaXRh
bG1hcnMtZC1sZWFybgp3cm90ZToKPiAKW+KApl0KPiBEVUIgZG93bmxvYWRzIHRoZSBzb3VyY2Ug
b2YgZGVwZW5kZW5jaWVzIGZyb20gZ2l0aHViIGFuZCBzdG9yZXPCoAo+IGl0IGFsbCBpbiB0aGUg
c3lzdGVtIGNhY2hlLiBFYWNoIHBhY2thZ2UgaGFzIGl0cyBvd24gdmVyc2lvbmVkwqAKPiBmb2xk
ZXIgaW4gdGhlIGNhY2hlIGFuZCwgd2hlbiBjb21waWxlZCwgaXMgZ2l2ZW4gYSAuZHViwqAKPiBz
dWJkaXJlY3RvcnkgaW4gdGhlIHBhY2thZ2Ugcm9vdC4gQmVuZWF0aCB0aGF0IGlzIGEgJ2J1aWxk
J8KgCj4gZGlyZWN0b3J5LCB3aXRoIG1vcmUgc3ViZGlyZWN0b3JpZXMgY29udGFpbmluZyB0aGUg
Y29tcGlsZWTCoAo+IGJpbmFyaWVzLCBlYWNoIGRpcmVjdG9yeSBuYW1lZCBhY2NvcmRpbmcgdG8g
dGhlIGJ1aWxkwqAKPiBjb25maWd1cmF0aW9uLgpb4oCmXQoKVGhpcyBpcyBub3Qgd2hhdCBzZWVt
cyB0byBoYXBwZW4gd2l0aCB1bml0LXRocmVhZGVkLiBmb3IgdGhlIGRpcmVjdG9yeSAKfi8uZHVi
L3BhY2thZ2VzL3VuaXQtdGhyZWFkZWQtMC43LjExL3VuaXQtdGhyZWFkZWQsIHRoZSB0cmVlIGlz
OgoKLgrilJzilIDilIAgYXBwdmV5b3IueW1sCuKUnOKUgOKUgCBkdWIuanNvbgrilJzilIDilIAg
ZXhhbXBsZQrilILCoMKgIOKUnOKUgOKUgCBleGFtcGxlX2ZhaWwuZArilILCoMKgIOKUlOKUgOKU
gCBleGFtcGxlX3Bhc3MuZArilJzilIDilIAgZ2VuCuKUgsKgwqAg4pSU4pSA4pSAIGdlbl91dF9t
YWluLmQK4pSc4pSA4pSAIGdlbl91dF9tYWluCuKUnOKUgOKUgCBsaWJ1bml0LXRocmVhZGVkLmEK
4pSc4pSA4pSAIExJQ0VOU0UK4pSc4pSA4pSAIG1zYnVpbGQucHJvagrilJzilIDilIAgUkVBRE1F
Lm1kCuKUnOKUgOKUgCBzb3VyY2UK4pSCwqDCoCDilJTilIDilIAgdW5pdF90aHJlYWRlZArilILC
oMKgwqDCoMKgwqDCoOKUnOKUgOKUgCBhc3NlcnRzLmQK4pSCwqDCoMKgwqDCoMKgwqDilJzilIDi
lIAgYXR0cnMuZArilILCoMKgwqDCoMKgwqDCoOKUnOKUgOKUgCBkdWIuZArilILCoMKgwqDCoMKg
wqDCoOKUnOKUgOKUgCBmYWN0b3J5LmQK4pSCwqDCoMKgwqDCoMKgwqDilJzilIDilIAgaW50ZWdy
YXRpb24uZArilILCoMKgwqDCoMKgwqDCoOKUnOKUgOKUgCBpby5kCuKUgsKgwqDCoMKgwqDCoMKg
4pSc4pSA4pSAIG1ldGEuZArilILCoMKgwqDCoMKgwqDCoOKUnOKUgOKUgCBtb2NrLmQK4pSCwqDC
oMKgwqDCoMKgwqDilJzilIDilIAgb3B0aW9ucy5kCuKUgsKgwqDCoMKgwqDCoMKg4pSc4pSA4pSA
IHBhY2thZ2UuZArilILCoMKgwqDCoMKgwqDCoOKUnOKUgOKUgCBwcm9wZXJ0eQrilILCoMKgwqDC
oMKgwqDCoOKUgsKgwqAg4pSU4pSA4pSAIHBhY2thZ2UuZArilILCoMKgwqDCoMKgwqDCoOKUnOKU
gOKUgCByYW5kb21pemVkCuKUgsKgwqDCoMKgwqDCoMKg4pSCwqDCoCDilJzilIDilIAgYmVuY2ht
YXJrLmQK4pSCwqDCoMKgwqDCoMKgwqDilILCoMKgIOKUnOKUgOKUgCBnZW4uZArilILCoMKgwqDC
oMKgwqDCoOKUgsKgwqAg4pSc4pSA4pSAIHBhY2thZ2UuZArilILCoMKgwqDCoMKgwqDCoOKUgsKg
wqAg4pSU4pSA4pSAIHJhbmRvbS5kCuKUgsKgwqDCoMKgwqDCoMKg4pSc4pSA4pSAIHJlZmxlY3Rp
b24uZArilILCoMKgwqDCoMKgwqDCoOKUnOKUgOKUgCBydW5uZXIuZArilILCoMKgwqDCoMKgwqDC
oOKUnOKUgOKUgCBydW50aW1lLmQK4pSCwqDCoMKgwqDCoMKgwqDilJzilIDilIAgc2hvdWxkLmQK
4pSCwqDCoMKgwqDCoMKgwqDilJzilIDilIAgdGVzdGNhc2UuZArilILCoMKgwqDCoMKgwqDCoOKU
nOKUgOKUgCB0ZXN0cwrilILCoMKgwqDCoMKgwqDCoOKUgsKgwqAg4pSc4pSA4pSAIGlzc3VlMzMu
ZArilILCoMKgwqDCoMKgwqDCoOKUgsKgwqAg4pSc4pSA4pSAIG1vY2tzLmQK4pSCwqDCoMKgwqDC
oMKgwqDilILCoMKgIOKUnOKUgOKUgCBtb2R1bGVfd2l0aF9hdHRycy5kCuKUgsKgwqDCoMKgwqDC
oMKg4pSCwqDCoCDilJzilIDilIAgbW9kdWxlX3dpdGhfc2V0dXAuZArilILCoMKgwqDCoMKgwqDC
oOKUgsKgwqAg4pSc4pSA4pSAIG1vZHVsZV93aXRoX3Rlc3RzLmQK4pSCwqDCoMKgwqDCoMKgwqDi
lILCoMKgIOKUnOKUgOKUgCBwYXJhbWV0cml6ZWQuZArilILCoMKgwqDCoMKgwqDCoOKUgsKgwqAg
4pSc4pSA4pSAIHN0cnVjdHNfYXJlX25vdF9jbGFzc2VzLmQK4pSCwqDCoMKgwqDCoMKgwqDilILC
oMKgIOKUlOKUgOKUgCB0YWdzLmQK4pSCwqDCoMKgwqDCoMKgwqDilJzilIDilIAgdGVzdHN1aXRl
LmQK4pSCwqDCoMKgwqDCoMKgwqDilJTilIDilIAgdWRhLmQK4pSc4pSA4pSAIHRlc3RzCuKUgsKg
wqAg4pSc4pSA4pSAIGZhaWwK4pSCwqDCoCDilILCoMKgIOKUnOKUgOKUgCBjb21wb3NpdGUuZAri
lILCoMKgIOKUgsKgwqAg4pSc4pSA4pSAIGRlbGF5ZWQuZArilILCoMKgIOKUgsKgwqAg4pSc4pSA
4pSAIGV4Y2VwdGlvbi5kCuKUgsKgwqAg4pSCwqDCoCDilJzilIDilIAga2xhc3MuZArilILCoMKg
IOKUgsKgwqAg4pSc4pSA4pSAIG5vcm1hbC5kCuKUgsKgwqAg4pSCwqDCoCDilJTilIDilIAgcHJp
di5kCuKUgsKgwqAg4pSU4pSA4pSAIHBhc3MK4pSCwqDCoMKgwqDCoMKgwqDilJzilIDilIAgYXR0
cmlidXRlcy5kCuKUgsKgwqDCoMKgwqDCoMKg4pSc4pSA4pSAIGRlbGF5ZWQuZArilILCoMKgwqDC
oMKgwqDCoOKUnOKUgOKUgCBmaXh0dXJlcy5kCuKUgsKgwqDCoMKgwqDCoMKg4pSc4pSA4pSAIGlv
LmQK4pSCwqDCoMKgwqDCoMKgwqDilJzilIDilIAgaXNzdWU1MS5kCuKUgsKgwqDCoMKgwqDCoMKg
4pSc4pSA4pSAIG1vY2suZArilILCoMKgwqDCoMKgwqDCoOKUnOKUgOKUgCBub3JtYWwuZArilILC
oMKgwqDCoMKgwqDCoOKUnOKUgOKUgCBwcm9wZXJ0eS5kCuKUgsKgwqDCoMKgwqDCoMKg4pSc4pSA
4pSAIHJlZ2lzdGVyLmQK4pSCwqDCoMKgwqDCoMKgwqDilJTilIDilIAgdHlwZXMuZArilJTilIDi
lIAgVE9ETy50eHQKCk5vdGUgdGhhdCB0aGUgZ2VuX3V0X21haW4gZXhlY3V0YWJsZSBhbmQgdGhl
IGxpYnVuaXQtdGhyZWFkZWQuYSBsaWJyYXJ5CmFyZSBhdCB0aGUgdG9wIGxldmVsIGFuZCBoYXZl
IHRvIHJlY29tcGlsZWQgZm9yIGVhY2gKY29uZmlndXJhdGlvbi9wbGF0Zm9ybSBjaGFuZ2UuIFRo
ZXJlIGlzIG5vIHNlcGFyYXRpb24gb2YgdGhlIHZhcmlvdXMKY29uZmlndXJhdGlvbnMgYW5kIHBs
YXRmb3Jtcy4KCi0tIApSdXNzZWwuCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CkRyIFJ1c3NlbCBXaW5k
ZXIgICAgICB0OiArNDQgMjAgNzU4NSAyMjAwICAgdm9pcDogc2lwOnJ1c3NlbC53aW5kZXJAZWtp
Z2EubmV0CjQxIEJ1Y2ttYXN0ZXIgUm9hZCAgICBtOiArNDQgNzc3MCA0NjUgMDc3ICAgeG1wcDog
cnVzc2VsQHdpbmRlci5vcmcudWsKTG9uZG9uIFNXMTEgMUVOLCBVSyAgIHc6IHd3dy5ydXNzZWwu
b3JnLnVrICBza3lwZTogcnVzc2VsX3dpbmRlcg==
Apr 11 2017
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 11 April 2017 at 11:13:30 UTC, Russel Winder wrote:

 This is not what seems to happen with unit-threaded. for the 
 directory ~/.dub/packages/unit-threaded-0.7.11/unit-threaded, 
 the tree is:
Just to be clear -- is this what you see after compiling a project that depends on unit-threaded, or did you do something like `dub build unit-threaded`?
Apr 11 2017
parent Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Tue, 2017-04-11 at 13:24 +0000, Mike Parker via Digitalmars-d-learn
wrote:
 On Tuesday, 11 April 2017 at 11:13:30 UTC, Russel Winder wrote:
=20
 This is not what seems to happen with unit-threaded. for the=C2=A0
 directory ~/.dub/packages/unit-threaded-0.7.11/unit-threaded,=C2=A0
 the tree is:
=20 Just to be clear -- is this what you see after compiling a=C2=A0 project that depends on unit-threaded, or did you do something=C2=A0 like `dub build unit-threaded`? =20
Actually for 0.7.11 I had done lots of fiddling so could not guarantee. However 0.7.13 appeared unexpectedly and so is a fresh install driven by an application build dependent on unit-threaded. It has the exact same structure. So it is the way Dub builds unit-threaded, requiring rebuild for every change of configuration or platform. --=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=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 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 11 2017
prev sibling parent reply drug <drug2004 bk.ru> writes:
11.04.2017 08:15, Russel Winder via Digitalmars-d-learn пишет:
 As I understand it, Dub compiles a downloaded dependency into the local
 Dub cache. This means you cannot store a debug build and a release
 build for multiple architectures and different compilers, at the same
 time, and you only get a .a file, no .so file.

 Cargo downloads source to the cache but compiles to the project area,
 separating debug and release builds. Each project has it's own
 compilation of the shared source.

 I believe Cargo has this right and Dub has this wrong. So wrong that
 SCons, CMake, and Meson have a strong role in the D world. As it
 stands, Dub is fine for fetching dependencies and then has no more role
 to play in the build of a project. Actually then the Dub command has no
 useful role since it may well be better for the build tools to just use
 the Dub repository API directly.

 Unless I have misunderstood Dub, or someone is fixing it.
There is possibility to place binaries to specified directory using `targetPath` (see `Build settings` in Dub documentation)
Apr 10 2017
parent Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Tue, 2017-04-11 at 09:57 +0300, drug via Digitalmars-d-learn wrote:
=20
[=E2=80=A6]
 There is possibility to place binaries to specified directory using=C2=A0
 `targetPath` (see `Build settings` in Dub documentation)
That is fine for the project code, but doesn't help with the dependencies. --=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=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 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 11 2017