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.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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

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.

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)

On Tue, 2017-04-11 at 06:45 +0000, Mike Parker via Digitalmars-d-learn wrote:
> 
[…]
> 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.
[…]

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:

.
├── appveyor.yml
├── dub.json
├── example
│   ├── example_fail.d
│   └── example_pass.d
├── gen
│   └── gen_ut_main.d
├── gen_ut_main
├── libunit-threaded.a
├── LICENSE
├── msbuild.proj
├── README.md
├── source
│   └── unit_threaded
│       ├── asserts.d
│       ├── attrs.d
│       ├── dub.d
│       ├── factory.d
│       ├── integration.d
│       ├── io.d
│       ├── meta.d
│       ├── mock.d
│       ├── options.d
│       ├── package.d
│       ├── property
│       │   └── package.d
│       ├── randomized
│       │   ├── benchmark.d
│       │   ├── gen.d
│       │   ├── package.d
│       │   └── random.d
│       ├── reflection.d
│       ├── runner.d
│       ├── runtime.d
│       ├── should.d
│       ├── testcase.d
│       ├── tests
│       │   ├── issue33.d
│       │   ├── mocks.d
│       │   ├── module_with_attrs.d
│       │   ├── module_with_setup.d
│       │   ├── module_with_tests.d
│       │   ├── parametrized.d
│       │   ├── structs_are_not_classes.d
│       │   └── tags.d
│       ├── testsuite.d
│       └── uda.d
├── tests
│   ├── fail
│   │   ├── composite.d
│   │   ├── delayed.d
│   │   ├── exception.d
│   │   ├── klass.d
│   │   ├── normal.d
│   │   └── priv.d
│   └── pass
│       ├── attributes.d
│       ├── delayed.d
│       ├── fixtures.d
│       ├── io.d
│       ├── issue51.d
│       ├── mock.d
│       ├── normal.d
│       ├── property.d
│       ├── register.d
│       └── types.d
└── TODO.txt

Note that the gen_ut_main executable and the libunit-threaded.a library are at the top level and have to recompiled for each configuration/platform change. There is no separation of the various configurations and platforms.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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

On Tue, 2017-04-11 at 09:57 +0300, drug via Digitalmars-d-learn wrote:
> 
[…]
> There is possibility to place binaries to specified directory using `targetPath` (see `Build settings` in Dub documentation)

That is fine for the project code, but doesn't help with the dependencies.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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

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`?

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:
> 
> > 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`?
> 

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.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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