compile "automation", makefile, or whatever?

[K.K. via Digitalmars-d-learn]

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