On Wed, 24 Sep 2014 21:44:26 -0700
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Make is the C++ of build systems. It may be ugly, but you can get it to work.
'make' reminds me assembler language: it's possible to do alot of cool things with 'make', but it's compilcated and tedious process. ah, and it's not the fastest kid on the block, so you'll not gain any speed using 'make'. ;-)

On Wed, Sep 24, 2014 at 11:14:30PM -0700, Walter Bright via Digitalmars-d wrote: [...]
> You noted my preference for simple makefiles (even if they tend to get verbose). I've been using make for 30 years now, and rarely have problems with it. Of course, I also eschew using every last feature of make, which too many people feel compelled to do. So no, my makefiles don't consist of "arcane hacks". They're straightforward and rather boring.
> 
> And I use make -j on posix for parallel builds, it works fine on dmd.

Well, I *am* grateful that building dmd is as simple as identifying which makefile to use for your platform, and make away. And the fact that building dmd with -j works. Sadly, 95% of non-trivial make-based projects out there require all manner of arcane hacks that break across platforms, requiring patch upon patches (*ahem*autotools*cough*) ostensibly to work, but in practice ends up breaking anyway and you're left with a huge mess to debug. And -j generally doesn't work. :-/ (It either crashes with obscure non-reproducible compile errors caused by race conditions, or gives you a binary that may or may not represent the source code. Sigh.)

In fact, one thing that impressed me immensely is the fact that building the dmd toolchain is as simple as it is. I know of no other compiler project that is comparable. Building gcc, for example, is a wondrous thing to behold -- when it works. When it doesn't (which is anytime you dare do the slightest thing not according to the meticulous build instructions)... it's nightmarish.

But even then, I *did* run into the problem of non-reproducible builds with dmd. So there's still a blemish there. :-P  Makes me want to alias `make` to `make clean; make` just for this alone... Oh wait, I've already done that -- I have a script for pulling git HEAD from github and rebuilding dmd, druntime, phobos, and it *does* run make clean before rebuilding everything! Sigh. The only redeeming thing is that dmd/druntime/phobos builds at lightning speed (relative to, say, the gcc toolchain), so this isn't *too* intolerable a cost. But still. It's one of my pet peeves about make...


T

-- 
Many open minds should be closed for repairs. -- K5 user

On Wed, 24 Sep 2014 23:14:30 -0700
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> And I use make -j on posix for parallel builds, it works fine on dmd.
me too. paired with `git clean -dxf` to get "clean of the cleanest possible" fileset. it's good that dmd build times are so low. ;-)

On Wed, 24 Sep 2014 23:22:56 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> gdb does allow calling your program's functions out-of-band in 'print'.
it's handy. what else handy is "quake-like" embedded console. i'm using that in my c software alot (i can connect to some port using telnet, inspect and change vars, call functions, etc). and when i decided to go with D, the first thing i tried to write was my "command console" subsystem. and it was a great pleasure with all that compile-time introspection, i must say. some annoyances here and there, but it's nothing compared to huge pile of error-prone C macro magic.

On 25/09/14 03:54, H. S. Teoh via Digitalmars-d wrote:

> Well, Cliff & I (and whoever's interested) will see what we can do about
> that. Perhaps in the not-so-distant future we may have a D build tool
> that can serve as the go-to build tool for D projects.

What problems do you see with Dub?

-- 
/Jacob Carlborg

> [...]
>> If you have a passion and interest in this space and would like to
>> collaborate, I would be thrilled.  We can also split this discussion
>> off of this thread since it is not D specific.
>
> I'm interested. What about Atila?

Definitely interested. BTW, I agree with everything you said about what would be desireable from a build system. Basically we had pretty much the same idea. :)

Atila

On Thu, 25 Sep 2014 09:04:43 +0200
Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> What problems do you see with Dub?
i, for myself, see a great problem with Dub: it's not a universal build tool. some of my internal D projects, for example, builds C libraries from source (and some of that libraries using yacc, for example, and others some other generator tools, which are build and execed in the process of building the library), then runs some kind of external generators (can't do this with D CTFE, 'cause compiler eats all of my RAM and then fails), then builds D sources, then links it all together.

it's complicated as it is, and Dub is not well-suited for such use cases.

On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via Digitalmars-d wrote:
> [...]
> Now throw in things like built-in parallelization ala SCons (I'm not
> sure if tup does that too, I suspect it does), 100%-reproducible builds,
> auto-packaging, etc., and we might have a contender for Andrei's
> "winner" build system.

Tup does parallels builds: in the company we were using scons, now cmake, tup and, well, dub.
Plus an internal one... *sigh*...

---
/Paolo

On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
>
> What do you think are the worst parts of D?
>

Anything in the spec that depends on you having an x86 CPU, or being tied to a specific platform.

1) D Inline Assembler.
- First because suddenly to have a conformant compiler you need to implement an entire assembler, rather than doing the sensible thing and just offloading it to GAS or some other tool that can assemble the code for you.
- Second because it creates so many holes, like invalidates nothrow checks, allows jumps to skip over initialisations, etc.

2) __simd
- The gentlemans equivalent of asm { di 0xF30F58, v1, v2; }

3) va_argsave_t implementation
- The brainchild of "let's get it working, then pretty" when it came to porting DMD to 64bit.  Everyone else managed to support 64bit va_list just fine for years without it.

4) Array operations only work if evaluation order is done from right to left.
- Contradictory to the rest of the language which promotes left to right evaluation.

5) CTFE'd Intrinsics
- First, there's a disparity between what is a compiler intrinsic and what is a ctfe intrinsic.  Eg: tan()
- Second, there is no use-case for being able to run at compile-time what is essentially a specialist x87 opcode.

6) Shared library support
- Still no documentation after 2 or more years of requesting it.

7) Interfacing with C++
- A new set of features that is danger of falling into the same "let's get it working" pit.  First warning sign was C++ template mangling, then DMD gave up on mangling D 'long' in any predictable way.  It's all been downhill from there.

On Thursday, 25 September 2014 at 07:34:11 UTC, Iain Buclaw wrote:
> On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
>>
>> What do you think are the worst parts of D?
>>
>
> Anything in the spec that depends on you having an x86 CPU, or being tied to a specific platform.
>

Special extra

8) Real
- What a pain.