Merging with trentforkert's work

[mathstuf]

Hi,

I'm working with @trentforkert on getting full D support into CMake (e.g., VisualD support, proper dependency management/discovery, and other things). I was wondering whether you'd be interested in bringing things from here into that branch (particularly the tests and the dub support).

[dcarp]

Hi,

What is the status of your work? Is it ready to be merged in CMake? Please send me a pointer to the branch you are working on.
My problem is that I don't use CMake at work anymore and at the moment is a not a priority for me.
On the other side, it would be great to have proper D support in CMake and I'll love to help you with the thinks that I've done already.

[mathstuf]

The status is that it works for me (Linux and GDC with a patched Ninja, but that patch may be unnecessary with the latest updates) and @trentforkert has done some more testing, but it isn't exactly close to upstreaming yet, IMO (3.2 would probably be a lofty goal right now). There's testing that needs written (though bringing the tests you have over would help that), dashboard machines need to be set up (with the cross product of platforms and compilers), and someone should step up to help maintain it because Kitware (also my employer) doesn't have enough D knowledge or experience right now to do proper maintenance, bug fixing, and backwards compatibility stuff. My personal interest in it is narrower than required (though I'll certainly help with things) and not directly related to my work at Kitware and as such, I'm unlikely to get any time to do so there as things stand.

That said, the latest code is at https://github.com/trentforkert/CMake/tree/d_support3.

[KingDuckZ]

Hello, is there any progress on this? Speaking to some people on #cmake on freenode, I've been told upstream is very likely to accept the pull request. I think mathstuf would know better than me anyways. I'm really looking forward to it. As it is now, using cmake-d is much easier because I can just add it as a submodule in my project and compile on any machine with a stock cmake. Switching to the fork would instead require me to manually install software from outside the repository, which makes it harder to keep up to date.

One possibility that I'd be willing to test, at least on some of my machines, is to install the forked cmake from an overlay (dlang for Gentoo). Hopefully that should help you get more feedback about outstanding issues, but that would also put pressure on the project as you might break other ebuilds.

[trentforkert]

You've commented on an issue on dcarp's cmake-d, but I'm assuming this was directed at my fork:

Hello, is there any progress on this?

My project's been on a bit of a hiatus, since it works for me (TM) and I've been waiting on some features to be added to the D compilers: namely, support for building shared libraries. This may see changes to the language grammar, which may be simple and not require changes to my parser, or they may be more complicated and break things. I've delayed my work, because when I last worked on it, D had just gotten shared library support on Linux on DMD and LDC, and while it seemed to me Windows and OS X shared libs were just around the corner, only in the last week have I heard about any progress on Windows (still nothing on OS X).

The main things left to do (apart from bug fixing) are:

1. Any changes needed to support building D shared libraries
2. Write test cases
3. Improve documentation some more

I could skip to 2 and 3, and write tests for everything but shared libraries, and deal with the fact that D wouldn't respect BUILD_SHARED, or I could do what I have been which is to wait until current D compilers would work with shared and go from there.

Speaking to some people on #cmake on freenode, I've been told upstream is very likely to accept the pull request. I think mathstuf would know better than me anyways.

That's encouraging, but we'll have to see.

As it is now, using cmake-d is much easier because I can just add it as a submodule in my project and compile on any machine with a stock cmake.

True, and depending on what you want it to do that'll certainly work for you.

Switching to the fork would instead require me to manually install software from outside the repository, which makes it harder to keep up to date.

I'd recommend just building it in (for instance) ~/cmake_build, and then generating your project with ~/cmake_build/bin/cmake. Then, you can easily pull updates to the source tree from git, and rebuild incrementally, no installation required. But yeah, I agree, having to build (manually) kind of sucks.

One possibility that I'd be willing to test, at least on some of my machines, is to install the forked cmake from an overlay (dlang for Gentoo). Hopefully that should help you get more feedback about outstanding issues, but that would also put pressure on the project as you might break other ebuilds.

I've considered setting up repositories for various distros on OBS, but that wouldn't help a Gentoo user.

[russel]

Given there has been no work on @trentforkert CMake fork for over 3 years, I assume that is now a dead end, and that this CMake addition by @dcarp is the way to go using CMake to build D codes.

[mathstuf]

No, @trentforkert's approach is the right one for the long run. It gets dependencies right (including for VS, Ninja, etc.) and integrates properly with IDEs (such as VisualD). It needs a rebase which involves a lot of work (I started, but ended up dropping it due to the time it was taking) if someone else would like to do that.

[KingDuckZ]

Anyone knows what happened to trentforkert? Did he abandon his cmake fork?
Btw I also tried rebasing, I got up to cmake 3.3 but I gave up there as I don't know how to proceed. I posted here to let him know but I got no reply so far.

[dcarp]

As far as I know he wanted to wait for dmd .dll support on windows and just afterwards do the PR/merge. But this was 3 years ago :(.

[mathstuf]

Yeah, CMake has moved a lot since then. It'd take a decent chunk of time to rebase the work at this point.