On Monday, 16 January 2017 at 19:44:34 UTC, Russel Winder wrote:
> On Mon, 2017-01-16 at 17:47 +0000, King_DuckZ via Digitalmars-d-learn wrote:
>> 
> […]
>> > Meson can build D stuff out of the box.
>> > 
>> 
>> Hadn't heard of this before, I'll have a look. Btw I don't see any mention of D on their home page.
>
> It is very nice. D seems to work OOTB.
>
> […]
>> I'm not saying we shouldn't be learning things, but time is limited and I'd rather practice my C++ or D than learn yet another build system, especially if I only have limited use for it :)
>
> Some of us find build fun.
>
> […]

One [more] year ahead, and I found this old thread I had forgotten about. In the meantime, trentforkert has stopped (apparently) working on cmake, and dcarp's has failed me for projects larger than a couple files. It also looks like it's not receiving updates anymore.

All of this kept me away from D. Now that gdc is rumoured to get merged into gcc 8 tho, is there any concrete chance of this happening? I think even rust (which came out after D) has decent cmake support at this point.

On Mon, 2018-02-26 at 20:28 +0000, King_DuckZ via Digitalmars-d-learn wrote:
> […]
> 
> One [more] year ahead, and I found this old thread I had forgotten about. In the meantime, trentforkert has stopped (apparently) working on cmake, and dcarp's has failed me for projects larger than a couple files. It also looks like it's not receiving updates anymore.

The DCarp CMake-D repository is active. If it doesn't work then it just needs more work.

> All of this kept me away from D. Now that gdc is rumoured to get merged into gcc 8 tho, is there any concrete chance of this happening? I think even rust (which came out after D) has decent cmake support at this point.

As far as I am aware CMake is not used for Rust, the vast majority of people use Cargo. This mean it is certain some Rust people will use CMake. :-)

It is worth noting that the Rust plugin to CLion does not require CMake, it uses Cargo. CLion not IDEA is not the focus of the Rust plugin due to debugging. CLion is the platform for all native code language for JetBrains as I understand it exacly because of debugging support. I believe the work on D plugin support for IntelliJ IDEA should refocus on CLion. It can still use Dub it seems, and it can get access to the debugging framework.

Clearly it would still be good in D had CMake support. It strikes me the DCarp's CMake-D repository is the one to support.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Tuesday, 27 February 2018 at 09:20:21 UTC, Russel Winder wrote:
> On Mon, 2018-02-26 at 20:28 +0000, King_DuckZ via Digitalmars-d-learn wrote:
>> […]
>> 
>> One [more] year ahead, and I found this old thread I had forgotten about. In the meantime, trentforkert has stopped (apparently) working on cmake, and dcarp's has failed me for projects larger than a couple files. It also looks like it's not receiving updates anymore.
>
> The DCarp CMake-D repository is active. If it doesn't work then it just needs more work.
>
>> All of this kept me away from D. Now that gdc is rumoured to get merged into gcc 8 tho, is there any concrete chance of this happening? I think even rust (which came out after D) has decent cmake support at this point.
>
> As far as I am aware CMake is not used for Rust, the vast majority of people use Cargo. This mean it is certain some Rust people will use CMake. :-)
>
> It is worth noting that the Rust plugin to CLion does not require CMake, it uses Cargo. CLion not IDEA is not the focus of the Rust plugin due to debugging. CLion is the platform for all native code language for JetBrains as I understand it exacly because of debugging support. I believe the work on D plugin support for IntelliJ IDEA should refocus on CLion. It can still use Dub it seems, and it can get access to the debugging framework.
>
> Clearly it would still be good in D had CMake support. It strikes me the DCarp's CMake-D repository is the one to support.

Right, I stand corrected about Rust, though as you say there are those who use it with CMake.
About cmake-d, there's this https://github.com/dcarp/cmake-d/issues/19, which I could work around. More seriously though, it doesn't track dependencies between .d files. So if for example you have:

// a.d
void foo() {}

// b.d
import a;
int main() { foo(); return 0; }

and compile it, all goes well. Now if you change a to be:

//a.d
void foo(a=10) { //use a somewhere }

and just 'make' then you're in for some really funky crash (it may not be the exact code, but I had a problem very similar to this). The only fix is make clean; make. This is really hard to spot as soon as you start having more than a couple files, and it's really something the build system should take care of. Unfortunately I don't think a purely scripted solution for cmake will ever be able to handle this problem.

Speaking of CLion, at this point I've pretty much abandoned it, vim is more than enough for me. My problem is mixing D with C and C++, and with being already so familiar with CMake that starting all over again just puts me off to the point I'd rather not do any D at all. Build systems are not my passion really, and learning CMake was already painful enough.

On Tuesday, 27 February 2018 at 14:32:54 UTC, King_DuckZ wrote:
> On Tuesday, 27 February 2018 at 09:20:21 UTC, Russel Winder wrote:
>> [...]
>
> Right, I stand corrected about Rust, though as you say there are those who use it with CMake.
> About cmake-d, there's this https://github.com/dcarp/cmake-d/issues/19, which I could work around. More seriously though, it doesn't track dependencies between .d files. So if for example you have:
>
> [...]

Are there any news at all about CMake support? Should I just give up?

On Tuesday, 27 February 2018 at 14:32:54 UTC, King_DuckZ wrote:
> ... My problem is mixing D with C and C++ ...

you found already Dragos cmake-d, but not sure if you also know Dragos talk about mixing D with C/C++.

If not, have a look:
https://gitlab.com/dcarp/MUCplusplus/tree/master/2016.01.28