On Monday, 27 January 2014 at 08:27:57 UTC, Atila Neves wrote:
>
> Right now I'm glad that flycheck highlights compilation errors for me in emacs, but unfortunately there is no way currently to pass it -I flags for different projects so any non-Phobos non-currentdir imports fail.

Here's what I do for flymake. I'm not suggesting it's great, but it works for me:

https://gist.github.com/gmfawcett/8656475

You can specify compiler options in a project-local file, d.flymake.opts, which gets included to the compiler call using the '@' directive.

Graham

On 28 January 2014 01:47, Atila Neves <atila.neves@gmail.com> wrote:

>
>  dub doesn't address my needs at all, but I've put crap loads of
>> time/energy
>> into the D extension for premake, which works well (
>> https://bitbucket.org/premakeext), although for some reason has never
>> really gotten any attention from the D community :(
>>
>
> Never heard of the extension until now.
>
>
>
>> It generates cross-language build scripts (ie, C/C++ and D code all
>> together in the same project) for make and many popular IDE's.
>> I use it for large scale projects that involve C/C++ engine library, D
>> front end code, and other ancillary libraries bolted on the side.
>>
>
> That's cool, and I might make use of this when mixing D and C/C++. What dub does do really well is just making any source package available. I wish I had that plus the full features of a build system like CMake all under one roof.


premake does everything cmake does (that I care about), and also ticks some
boxes (that I make heavy use of) that cmake lacks; like supporting games
consoles and stuff like that.
I've never been happy with cmake, but premake is fairly nice, and it's
fully scriptable if it's idea of something is just not quite right.

Only problem is, there's been heaps of development on premake, homing in on premake5, mainly in terms of extensibility. But it's not yet available as binary packages. My extensions for D and other IDE's and toolchains all work against the trunk premake5 code.

On 28 January 2014 11:16, Manu <turkeyman@gmail.com> wrote:

> On 28 January 2014 01:47, Atila Neves <atila.neves@gmail.com> wrote:
>
>>
>>  dub doesn't address my needs at all, but I've put crap loads of
>>> time/energy
>>> into the D extension for premake, which works well (
>>> https://bitbucket.org/premakeext), although for some reason has never
>>> really gotten any attention from the D community :(
>>>
>>
>> Never heard of the extension until now.
>>
>>
>>
>>> It generates cross-language build scripts (ie, C/C++ and D code all
>>> together in the same project) for make and many popular IDE's.
>>> I use it for large scale projects that involve C/C++ engine library, D
>>> front end code, and other ancillary libraries bolted on the side.
>>>
>>
>> That's cool, and I might make use of this when mixing D and C/C++. What dub does do really well is just making any source package available. I wish I had that plus the full features of a build system like CMake all under one roof.
>
>
> premake does everything cmake does (that I care about), and also ticks
> some boxes (that I make heavy use of) that cmake lacks; like supporting
> games consoles and stuff like that.
> I've never been happy with cmake, but premake is fairly nice, and it's
> fully scriptable if it's idea of something is just not quite right.
>
> Only problem is, there's been heaps of development on premake, homing in on premake5, mainly in terms of extensibility. But it's not yet available as binary packages. My extensions for D and other IDE's and toolchains all work against the trunk premake5 code.
>

I should add, onthe plus side, premake is a single self-contained exe with
no runtime dependencies.
I typically build a binary, and just commit it to my project's bin/ folder,
and it just works, so others that want to build my projects don't have to
stuff around trying to build it.

On Monday, 27 January 2014 at 13:12:56 UTC, Manu wrote:
> D doesn't have a preprocessor or a horrible network of text include, it
> should easily be able to match the C# experiences in general.

No, it's much, much harder because of templates and string mixins.

The only way to get a solid auto-complete experience for D is to use a compiler-as-library, which is why I think the approach that VisualD and Mono-D (and DScanner to some extent, IIRC) takes is a colossal waste of time, as "good enough" will in fact never be good enough.

On 28 January 2014 13:43, Jakob Ovrum <jakobovrum@gmail.com> wrote:

> On Monday, 27 January 2014 at 13:12:56 UTC, Manu wrote:
>
>> D doesn't have a preprocessor or a horrible network of text include, it should easily be able to match the C# experiences in general.
>>
>
> No, it's much, much harder because of templates and string mixins.
>
> The only way to get a solid auto-complete experience for D is to use a compiler-as-library, which is why I think the approach that VisualD and Mono-D (and DScanner to some extent, IIRC) takes is a colossal waste of time, as "good enough" will in fact never be good enough.
>

Yeah, good point. I've heard murmurings of kitting DMD frontend out as a lib for tooling being thrown around as long as I've been trolling here. It must be really hard... or really really uninteresting :)

On Tuesday, 28 January 2014 at 03:43:11 UTC, Jakob Ovrum wrote:
> On Monday, 27 January 2014 at 13:12:56 UTC, Manu wrote:
>> D doesn't have a preprocessor or a horrible network of text include, it
>> should easily be able to match the C# experiences in general.
>
> No, it's much, much harder because of templates and string mixins.

Agreed. D is a language that almost seems like it was designed to maximize the difficulty of creating a complete autocomplete engine. As soon as you hit a line that looks like

mixin (someRandomTemplate!(a, b, c)(d, e, f));

you need a full compiler front-end to provide complete autocomplete.

> The only way to get a solid auto-complete experience for D is to use a compiler-as-library, which is why I think the approach that VisualD and Mono-D (and DScanner to some extent, IIRC) takes is a colossal waste of time, as "good enough" will in fact never be good enough.

If they were a waste of time nobody would use them.

Support of MSVC COFF is really needed for me.
And x64 codegen without any dependencies like msvc's link.exe linker.

Better tooling is one of the things that makes me write less D Code.

Basically I want Semantic Analysis, code completion, refactoring tools
as good as what I get with KDevelop on Linux and Debugging support
that is better than that.
I really like rdmd but I still get occasional bugs with it.

On Tue, Jan 28, 2014 at 4:05 PM, Temtaime <temtaime@gmail.com> wrote:
> Support of MSVC COFF is really needed for me.
> And x64 codegen without any dependencies like msvc's link.exe linker.

On Monday, 27 January 2014 at 10:28:29 UTC, Rikki Cattermole wrote:
> I can understand why you think about how I work, the way you do. Its like the difference between an introvert and an extravert. Its just so different way of working and thinking. Its unbelievable.
>
> I have honestly never meet somebody who works even similar to me.

Well, I guess if the sock fits wear it :D

I just know I'd be lost without my step-through code in larger projects with many people working on them.

The current situation in D is actually adequate for us. GDB gets it wrong sometimes but never so badly that we cannot immediately see through it to the truth in the code.

On Sunday, 26 January 2014 at 21:14:59 UTC, Namespace wrote:

> Detection of unused imports and variables!

Yes, that would be nice. They just creep in after a while. Common auto-completion (as in Textadept) is not perfect for things like

MyStruct!string("hello"); // It stops after MyStruct

However, given the lack of tools for D (in comparison to other languages) it is amazing how far you get in D with only a text editor and a Terminal application.