• CC (19/19) Jul 29 2018 Before starting with D programming, most of my projects have
• Alex (6/25) Jul 30 2018 For example, you could define
• CC (13/24) Jul 30 2018 Thanks Alex. IIUC what you're proposing is close to what I'd
• Seb (9/19) Jul 30 2018 Yes one typically uses dub within the source, e.g. `dub` (or `dub
• Bastiaan Veelo (5/18) Jul 30 2018 I haven’t tried it, but from the docs it seems that

CC <nospam gmail.com> writes:

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?

Alex <sascha.orlov gmail.com> writes:

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

CC <nospam gmail.com> writes:

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.

Seb <seb wilzba.ch> writes:

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.)

Bastiaan Veelo <Bastiaan Veelo.net> writes:

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.