Before starting with D programming, most of my projects have configured their build systems with Autotools or CMake, and git for source control.

With those systems, it's usually considered best practice to store all files generated during configuration and build to be located outside of the source tree.

My usual modus operandi is:
1. check out the project into some directory "foo".
2. create another directory "foo.build", somewhere outside of "foo".
3. "cd foo.build"
4. Run some configuration script/file located in "foo", to generate "foo.build/Makefile".
5. Run "make".

I've started playing with "dub", and it *seems* to assume that you want the files generated during the build process to reside directly inside your checked-out source tree.

Is that true?  And if so, am I fighting dub's design by attempting out-of-source builds?

On Monday, 30 July 2018 at 01:50:23 UTC, CC wrote:
> Before starting with D programming, most of my projects have configured their build systems with Autotools or CMake, and git for source control.
>
> With those systems, it's usually considered best practice to store all files generated during configuration and build to be located outside of the source tree.
>
> My usual modus operandi is:
> 1. check out the project into some directory "foo".
> 2. create another directory "foo.build", somewhere outside of "foo".
> 3. "cd foo.build"
> 4. Run some configuration script/file located in "foo", to generate "foo.build/Makefile".
> 5. Run "make".
>
> I've started playing with "dub", and it *seems* to assume that you want the files generated during the build process to reside directly inside your checked-out source tree.
>
> Is that true?  And if so, am I fighting dub's design by attempting out-of-source builds?

For example, you could define
"targetPath"
within the dub configuration, which points to a relative path somewhere.

[1] https://code.dlang.org/package-format?lang=json

On Monday, 30 July 2018 at 07:34:04 UTC, Alex wrote:
>> I've started playing with "dub", and it *seems* to assume that you want the files generated during the build process to reside directly inside your checked-out source tree.
>>
>> Is that true?  And if so, am I fighting dub's design by attempting out-of-source builds?
>
> For example, you could define
> "targetPath"
> within the dub configuration, which points to a relative path somewhere.
>
> [1] https://code.dlang.org/package-format?lang=json

Thanks Alex.  IIUC what you're proposing is close to what I'd need for true out-of-source builds, but not quite there.

With "targetPath", it sounds like I'd need to modify a file (DUB's .json file) that's in the source tree to indicate where some(?)/all(?) of the files resulting from the build would be stored.

But it sounds like I'm maybe fighting DUB's design by even attempting out-of-source builds.  So I need to ask: when using Dlang and DUB, are in-source builds simply the idiomatic way of doing things?

As much as I'm a fan of out-of-source builds, I'm trying to be open-minded as I dive into D.

On Monday, 30 July 2018 at 01:50:23 UTC, CC wrote:
[...]
> My usual modus operandi is:
> 1. check out the project into some directory "foo".
> 2. create another directory "foo.build", somewhere outside of "foo".
> 3. "cd foo.build"
> 4. Run some configuration script/file located in "foo", to generate "foo.build/Makefile".
> 5. Run "make".
>
> I've started playing with "dub", and it *seems* to assume that you want the files generated during the build process to reside directly inside your checked-out source tree.
>
> Is that true?  And if so, am I fighting dub's design by attempting out-of-source builds?

I haven’t tried it, but from the docs it seems that “--temp-build” does an out-of-source build, although it’s not exactly like your modus operandi.

On Monday, 30 July 2018 at 10:23:06 UTC, CC wrote:
> With "targetPath", it sounds like I'd need to modify a file (DUB's .json file) that's in the source tree to indicate where some(?)/all(?) of the files resulting from the build would be stored.

Yes.

> But it sounds like I'm maybe fighting DUB's design by even attempting out-of-source builds.  So I need to ask: when using Dlang and DUB, are in-source builds simply the idiomatic way of doing things?

Yes one typically uses dub within the source, e.g. `dub` (or `dub build`).

> As much as I'm a fan of out-of-source builds, I'm trying to be open-minded as I dive into D.

There might be another way. Dub can generate Cmake files:

dub generate cmake

Though I think you'll need cmake-d (https://github.com/dcarp/cmake-d) for it (disclaimer: I never played with dub's support for cmake.)