On Tuesday, 25 March 2014 at 01:15:10 UTC, Trent Forkert wrote:
> On Monday, 24 March 2014 at 23:55:14 UTC, Dragos Carp wrote:
>>>
>>> Any alternatives??
>>
>> I moved cmaked2 to github [1], updated and simplified the usage a
>> little (system cmake patch not necessary anymore). You can give
>> it a try. Dub registry support is also on the way.
>>
>> Regards
>> Dragos
>>
>>
>> [1] - https://github.com/dcarp/cmake-d
>
> Heh, seems I waited a bit too long, eh? I've been gearing up to do an initial release of some modifications to CMake that give better D support. (To clarify: this isn't being merged upstream yet, but hopefully that'll happen eventually)
>
> While the approach taken by CMakeD2 and cmake-d gets a good amount of the way there, it lacks key CMake features. Namely: Visual Studio support, which unfortunately requires patching the C++ source.
>
> The module-only approach also cannot support LDC (save via ldmd, which is not ideal), as CMake will think it is a linker. There were other problems I encountered that required changes to the C++ code as well, though I don't recall what they were off the top of my head.

Realized late last night that I misspoke. LDC and LDMD will
both be detected as a linker, and the change to fix that
doesn't touch the C++ source, but it does need to be done in
CMake's internal modules.

 - Trent

>
> I'm curious to see how you intend to do dub support, though.
>
>  - Trent

On Monday, 24 March 2014 at 23:55:14 UTC, Dragos Carp wrote:
> I moved cmaked2 to github [1], updated and simplified the usage a
> little (system cmake patch not necessary anymore). You can give
> it a try. Dub registry support is also on the way.
>
> [1] - https://github.com/dcarp/cmake-d

Verified tested and working on CentOS 6.5 with cmake28 package
from epel repository.

Thanks!
--
Chris

On Monday, 24 March 2014 at 23:55:14 UTC, Dragos Carp wrote:
> I moved cmaked2 to github [1], updated and simplified the usage a little (system cmake patch not necessary anymore). You can give
> it a try. Dub registry support is also on the way.
>
> Dragos

What is the best way to specify a mixin include directory for dmd
under
CMake?  I can arbitarily add a -J option to the compiler flags
but should
the cmake-d module include a variable that should be set?

--
Chris

On Friday, 9 May 2014 at 21:11:54 UTC, Chris Piker wrote:
> On Monday, 24 March 2014 at 23:55:14 UTC, Dragos Carp wrote:
>> I moved cmaked2 to github [1], updated and simplified the usage a little (system cmake patch not necessary anymore). You can give
>> it a try. Dub registry support is also on the way.
>>
>> Dragos
>
> What is the best way to specify a mixin include directory for dmd
> under
> CMake?  I can arbitarily add a -J option to the compiler flags
> but should
> the cmake-d module include a variable that should be set?
>
> --
> Chris

The way I've tackled that in my (still work-in-progress) CMake fork[1] is to add an `include_directories(TEXT ...)` signature. Unfortunately, you'll need to build my CMake from source, though that isn't difficult. Also, while I am hopeful about getting my changes merged upstream, there is no guarantee of that, so proceed with caution.

Do note that my CMake work is independent of CMakeD2 and its forks. See my project wiki for more info.

 - Trent

[1] https://github.com/trentforkert/cmake

On Friday, 9 May 2014 at 21:43:04 UTC, Trent Forkert wrote:

> The way I've tackled that in my (still work-in-progress) CMake fork[1] is to add an `include_directories(TEXT ...)` signature.

I like that, it seems clean.

> Unfortunately, you'll need to build my CMake from source, though that isn't difficult. Also, while I am hopeful about

The standard CMake build instructions just don't work on the
CentOS 6.5 systems we are currently using at work.  I gave
up after 2 hours. Since CMakeD2 is working for me I'm sticking
with it for now but...

> getting my changes merged upstream, there is no guarantee of that, so proceed with caution.

... it would be great to have better D support in CMake, I
really hope your changes do get committed upstream.  I plan
on using D somewhat quitely for about a year and after I've
worked out the gotcha's start talking to my programming friends.
An upstream merge would get used.

> Do note that my CMake work is independent of CMakeD2 and its forks. See my project wiki for more info.
>
> [1] https://github.com/trentforkert/cmake

Thanks, I'll check it out.
--
Chris