Hello all,
Given the recent chatter and movement on CMake D support, I've
decided to go public with a project of mine earlier than I had
intended.
Before I go further, a request: do *not* post this to
HN/reddit/etc just yet. It is still in early stages and an
upstream CMake 3.0 release (wit
On Tue, Mar 25, 2014 at 17:50:30 +, Trent Forkert wrote:
> It's CMake, with various modifications to work toward making D a
> first-class citizen of the CMake world.
>
> While other projects exist that attempt to add D support, they all do
> so without touching CMake's C++ sources. This means
On Tue, Mar 25, 2014 at 14:12:45 -0400, Ben Boeckel wrote:
> I'll try it out when I get a chance.
I've pushed some fixes to my CMake fork to work with GDC on Linux. I've
also fixed up some things I saw and opened a bug on your fork (which
isn't linked with Kitware/CMake, so PRs are unavailable…an
On Wednesday, 26 March 2014 at 06:17:57 UTC, Ben Boeckel wrote:
On Tue, Mar 25, 2014 at 14:12:45 -0400, Ben Boeckel wrote:
I'll try it out when I get a chance.
I've pushed some fixes to my CMake fork to work with GDC on
Linux. I've
also fixed up some things I saw and opened a bug on your fork
I have a quandary you might be able to help with, Ben.
I've been working on moving dependency resolution things to
cmDependsD.cxx, and I've got it mostly working.
However, if we have gdc produce make-style dependencies (which
will still require processing to get CMake to be happy), that
requ
On Wed, Mar 26, 2014 at 22:52:43 +, Trent Forkert wrote:
> However, if we have gdc produce make-style dependencies (which will
> still require processing to get CMake to be happy), that requires me
> to put a special case in the C++ that I'd rather not have.
I'm fine with either, but make-styl
On Wednesday, 26 March 2014 at 23:17:31 UTC, Ben Boeckel wrote:
What about:
4. Add depfile support to Makefile generators.
That's basically what I'm doing, though only in the context of D.
cmDependsD::WriteDependencies() gets called for every D object,
and has the D compiler produce a dmd-s
On Thu, Mar 27, 2014 at 00:38:05 +, Trent Forkert wrote:
> On Wednesday, 26 March 2014 at 23:17:31 UTC, Ben Boeckel wrote:
> > 4. Add depfile support to Makefile generators.
>
> That's basically what I'm doing, though only in the context of D.
No, I meant, using the DEPFLAGS during the make
On Thursday, 27 March 2014 at 01:16:57 UTC, Ben Boeckel wrote:
On Thu, Mar 27, 2014 at 00:38:05 +, Trent Forkert wrote:
On Wednesday, 26 March 2014 at 23:17:31 UTC, Ben Boeckel wrote:
> 4. Add depfile support to Makefile generators.
That's basically what I'm doing, though only in the conte
On Thu, Mar 27, 2014 at 01:52:00 +, Trent Forkert wrote:
> I've tested this by creating a wrapper script around dmd to log calls
> to it in a file. Using that, I can confirm that cmDependsD does
> nothing at configure time. Granted it didn't refresh the deps file
> when I updated my D code, but
On 26 March 2014 23:17, Ben Boeckel wrote:
> On Wed, Mar 26, 2014 at 22:52:43 +, Trent Forkert wrote:
>> However, if we have gdc produce make-style dependencies (which will
>> still require processing to get CMake to be happy), that requires me
>> to put a special case in the C++ that I'd rath
On Thu, Mar 27, 2014 at 17:21:45 +, Iain Buclaw wrote:
> Ain't the dmd-style deps legacy from a failed D build system?
>
> It's just kept around cause more recent/current build systems /may/
> find it's output useful.
Well, it's what we have currently. We could add support for
gcc-compatible
FWIW, I just pushed my implementation of cmDependsD[1], and found
dmd-style deps much nicer to work with. I used the >=2.064
ability to do
dmd -c -o- -deps foo.d
since that also contains file imports, which are technically
dependencies. I missed when/if this was discussed on the list,
bu
This is all very interesting. I have two questions.
1. Do you plan to get this merged back into CMake proper?
2. Could I use it to handle my weird build process?
At the moment I am working on something which requires
a strange build process, and I have been struggling to
implement it with existi
On Tuesday, 1 April 2014 at 12:46:54 UTC, w0rp wrote:
This is all very interesting. I have two questions.
1. Do you plan to get this merged back into CMake proper?
Ideally, yes. But things are still in early stages, and that is
up to people who aren't me. Perhaps Ben can shed light on if
Kit
On Tue, Apr 01, 2014 at 14:47:51 +, Trent Forkert wrote:
> On Tuesday, 1 April 2014 at 12:46:54 UTC, w0rp wrote:
> >1. Do you plan to get this merged back into CMake proper?
>
> Ideally, yes. But things are still in early stages, and that is up to
> people who aren't me. Perhaps Ben can shed l
On Tuesday, 25 March 2014 at 17:50:32 UTC, Trent Forkert wrote:
Hello all,
Given the recent chatter and movement on CMake D support, I've
decided to go public with a project of mine earlier than I had
intended.
Before I go further, a request: do *not* post this to
HN/reddit/etc just yet. It
On Tue, Apr 01, 2014 at 20:11:02 +, Meta wrote:
> Is this ready to be posted to HN/Reddit, or still no-go?
No idea, it's Trent's work for the most part, so that's his call.
However, I would like to get this to the CMake list sometime soon
(within a month?) for feedback before too many start us
On Tuesday, 1 April 2014 at 20:11:03 UTC, Meta wrote:
Is this ready to be posted to HN/Reddit, or still no-go?
I'm going to have to say no. A couple of major problems off the
top of my head:
1. I've recently had to shrink the fully supported compilers list
to DMD master and GDC 2.064 or gr
On Wednesday, 2 April 2014 at 03:34:14 UTC, Ben Boeckel wrote:
However, I would like to get this to the CMake list sometime
soon
(within a month?) for feedback before too many start using it
externally
(especially since getting it on the radar for 3.1 would be
nice).
I can probably manage tha
On Wed, Apr 02, 2014 at 03:59:47 +, Trent Forkert wrote:
> My understanding of INTERFACE properties is that they are used when
> dealing with importing/exporting targets. If this is the case, I'm
> not sure of a case when text includes would need to be provided
> through this. Text imports work
21 matches
Mail list logo
