On Tuesday, 16 September 2014 at 21:05:18 UTC, K.K. wrote:
> On Tuesday, 16 September 2014 at 20:53:08 UTC, Cliff wrote:
>> Would you be willing to provide some more detail on what about it
>> you didn't like (errors, missing features, etc.)?  I ask because
>> build systems are a particular interest of mine and I have
>> projects in this area which can always use more user data.
>
> I'll try, but I haven't used it at all since maybe.. April?
>
> One of the main things that annoyed me about it was how sensitive
> it could be. The best comparison I can give is that it reminded
> me ALOT of Haxe. Both are very flimsy, and very poorly
> documented. (Nothing beats a good manual as far as I'm concerned!)
>
> The other thing, as I briefly mentioned, was it really didn't
> speed anything up, unless maybe you were working on a larger
> project.
>
>
> Obviously I'm not a master of any sort, but the main point I'd
> take from this is it wasn't inviting.
>
> Hope that helps a bit :3

Yep, that's useful information to me.  Over the years I have
found that build systems *generally* tend to be uninviting.  My
suspicion is that comes down to a few reasons:

1. Builds end up being a LOT more complicated that you would
expect as soon as you step out of a single project with a few
source files and default options
2. Build tooling is typically built and maintained by people who
end up being relatively specialist - either they are part of the
small cabal of people who know the tooling intimately, or they
have been forced into it and know just enough to get by for their
organization.
3. Most build tooling is designed to solve a particular subset of
actual build-related problems, with much less though given to how
it fits holistically into the entire developer workflow.
4. Build tooling is almost never treated like an actual product -
documentation is written for wizards, not lay-people.

As a result, the casual user is a bit SOL.

(NOTE: This is not a rant specifically aimed at DUB, but my
general observation on the state of build tooling.)

On Tuesday, 16 September 2014 at 21:17:19 UTC, Cliff wrote:
> On Tuesday, 16 September 2014 at 21:05:18 UTC, K.K. wrote:
>> On Tuesday, 16 September 2014 at 20:53:08 UTC, Cliff wrote:
>>> Would you be willing to provide some more detail on what about it
>>> you didn't like (errors, missing features, etc.)?  I ask because
>>> build systems are a particular interest of mine and I have
>>> projects in this area which can always use more user data.
>>
>> I'll try, but I haven't used it at all since maybe.. April?
>>
>> One of the main things that annoyed me about it was how sensitive
>> it could be. The best comparison I can give is that it reminded
>> me ALOT of Haxe. Both are very flimsy, and very poorly
>> documented. (Nothing beats a good manual as far as I'm concerned!)
>>
>> The other thing, as I briefly mentioned, was it really didn't
>> speed anything up, unless maybe you were working on a larger
>> project.
>>
>>
>> Obviously I'm not a master of any sort, but the main point I'd
>> take from this is it wasn't inviting.
>>
>> Hope that helps a bit :3
>
> Yep, that's useful information to me.  Over the years I have
> found that build systems *generally* tend to be uninviting.  My
> suspicion is that comes down to a few reasons:
>
> 1. Builds end up being a LOT more complicated that you would
> expect as soon as you step out of a single project with a few
> source files and default options
> 2. Build tooling is typically built and maintained by people who
> end up being relatively specialist - either they are part of the
> small cabal of people who know the tooling intimately, or they
> have been forced into it and know just enough to get by for their
> organization.
> 3. Most build tooling is designed to solve a particular subset of
> actual build-related problems, with much less though given to how
> it fits holistically into the entire developer workflow.
> 4. Build tooling is almost never treated like an actual product -
> documentation is written for wizards, not lay-people.
>
> As a result, the casual user is a bit SOL.
>
> (NOTE: This is not a rant specifically aimed at DUB, but my
> general observation on the state of build tooling.)

Yeah I absolutely agree with you on that!

Something I see alot in place of actual documentation is the
developer repeatedly saying "email me" (aka google searching
peoples name's and usernames until you find it), but I'm
generally reluctant to do so because it means I'm gonna have to
ask them very straight forward streamlined questions (usually
meaning I'd have to take my problem out of the context I'm having
trouble with) and then pray that they'll answer more than one
email, and also hope they'll answer within at least a few days.
Some people are really good an answer within a few hours, other
times you won't get a reply at all.

Also when reading your post i remembered something else about
DUB.. I don't remember precisely what I was doing, but I had a
quick experiment that was just supposed a window opened and
displayed a small image. Using DMD it worked fine, but for some
reason when using DUB, the picture wouldn't load at all. It was
quite the mystery.
So you can probably see why I've happily made text files,
folders, and powershell my go to tools :P

On Tuesday, 16 September 2014 at 20:31:33 UTC, Cliff wrote:
> On Tuesday, 16 September 2014 at 20:29:12 UTC, K.K. wrote:
>> On Tuesday, 16 September 2014 at 19:26:29 UTC, Cliff wrote:
>>> I want to say somewhere on the forums are some descriptions of
>>> using CMake for this.  Might try searching for that.
>>
>> Yeah I just looked up the CMake thing. It definitely seems worth
>> playing with, though I'm not really sure how extensive it's D
>> support currently is :S
>
> Out of curiosity, why are you not using dub (on the command-line)?

Is dub intended to be a replacement for make? I've never used it beyond just playing around with it here and there, but my impression was that it is wonderful if you're doing a pure D project and have a dependency on some of the libraries in their repository. In my case, I'm calling libraries on my local machine that I wrote and linking to existing C libraries. I couldn't figure out how to do that in dub, but given that the alternative was to type a few lines into a Makefile, I didn't see the point.

On Tuesday, 16 September 2014 at 21:54:10 UTC, bachmeier wrote:
> In my case, I'm calling libraries on my local machine that I wrote and

I didn't use dub, but according to docs you can write

 "dependencies": {
  "mylib2": { "path": "../mylib2" }
 },

or something like that

> linking to existing C libraries.

systemDependencies 	string 	A textual description of the required system dependencies (external C libraries) required by the package. This will be visible on the registry and will be displayed in case of linker errors.

libs 	string[] 	A list of external library names - depending on the compiler, these will be converted to the proper linker flag (e.g. "ssl" might get translated to "-L-lssl")