On 26 March 2014 23:17, Ben Boeckel <mathstuf@gmail.com> wrote:
> On Wed, Mar 26, 2014 at 22:52:43 +0000, 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-style is preferred since it can exclude system files (which I've asked LDC about supporting as well; should ask dmd too).
>
>> The way I see it, there are three possibilities here:
>> 1. Keep gdc producing make-style deps, and deal with that as needed.
>> 2. Have gdc produce dmd-style deps, and let the patched Ninja you
>> mentioned use that.
>> 3. Have a separate flag registered for the two different styles of
>> dependencies.
>>
>> I'm quite partial to number 3, as I could then use that to check which flags are defined for which style is supported, and act accordingly. I prefer that to hardcoding "gdc does this. Anything else does this other thing."
>
> What about:
>
>   4. Add depfile support to Makefile generators.
>
> It seems that it shouldn't be *too* hard[1] to do. Obviously, dmd-style deps will still have problems with make, but we could try and ask the dmd and ldc upstream to at least support Make-style dependency files (this would mean old dmd/ldc + make isn't supported, but at least Ninja would be an option there). If that fails, some CMake code to generate Make-style .d files from dmd-style shouldn't be too bad (some regex matching and character escaping should do the trick).
>

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.

On Thu, Mar 27, 2014 at 17:21:45 +0000, 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 depfiles, but then you're stuck with only new versions of DMD or LDC if you use CMake. Adding support to CMake and Ninja is much easier than upgrading the compiler since they're much smaller and more easily upgradable (fewer moving parts, lower chance of getting subtle new behavior[1], more reasonable to expect or ask users to have an up-to-date version, etc.).

Getting the -M flags recognized and implemented in DMD and LDC are good goals to shoot for, but we're constrained by the tools we have available…

--Ben

[1]CMake is (ideally) loud when this occurs through its policy system.m

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, but it seems that form of dependency output at least is intended to stay, even if it forces us to drop support for older compiler versions.

 - Trent

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

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 existing build tools. First it needs to
compile and run a D program, which generates .d and .cpp files. Then,
it needs to take all of those D and C++ sources and build one library
out of them. This all works, I just need to get a build tool that
does it all in one 'make' command or similar.

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 Kitware wants something like this upstream. However, I effectively need CMake for a personal project, so I'll continue maintaining this even if Kitware refuses an upstream merge. Once things stabilize a bit more, I'll keep up-to-date binaries published, too.

> 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 existing build tools. First it needs to
> compile and run a D program, which generates .d and .cpp files. Then,
> it needs to take all of those D and C++ sources and build one library
> out of them. This all works, I just need to get a build tool that
> does it all in one 'make' command or similar.

Yep, that sort of thing works:

CMakeLists.txt:

    cmake_minimum_required(VERSION 3.0)
    project(example D)

    add_executable(codegen codegen.d)
    add_custom_command(
        OUTPUT generated.d
        COMMAND codegen
    )
    add_library(generated generated.d)


codegen.d:
    import std.file;

    void main()
    {
        "generated.d".write(q{
            int myfunc()
            {
                return 42;
            }
        });
    }

Then, to use CMake to generate Makefiles (or various other build systems) and build:

    mkdir ../path/to/builddir
    cd ../path/to/builddir
    cmake ../path/to/sourcedir
    make -j4

Luckily for you, an old pet project of mine does something similar to what you describe. I intend on reviving it in the near future, and moving from a hacky shell script build system to a CMake one. So, if something breaks, I'll be sure to fix it.

Be warned, however, that this project is still subject to significant changes. For instance, I'm in the process of replacing include_text_directories with include_directories(TEXT), and thus improving the way -J flags are managed. I'm sure other things will come up and need changed as we encounter bugs.

 - Trent

On Tue, Apr 01, 2014 at 14:47:51 +0000, 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 light on if Kitware wants something like this upstream. However, I effectively need CMake for a personal project, so I'll continue maintaining this even if Kitware refuses an upstream merge. Once things stabilize a bit more, I'll keep up-to-date binaries published, too.

I believe it'd only be accepted if you (or someone else from the D community) stick around and help with support. I'm the only one here who seems to have an interest in D (and, most likely, mine is really only here for as long as I'm working with the abagames ports I'm doing in my free time). I doubt it'd be accepted if it is just a code dump onto Kitware since CMake has some strict backwards compatibility requirements and there are no D experts readily available.

--Ben

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 is still in early stages and an upstream CMake 3.0 release (without D support) is incoming. Announcing this far and wide will only yield confusion at this time.
>
> So, what is this?
>
> 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 that they will inevitably fall short of the mark.
>
> Additionally, when I first started toying with this several months ago, there were a lot of implementation/design issues in the existing projects, that went against the way CMake's internals expect things to be done. I'm not sure how the current scene is in that regard.
>
> Status
>
> * GDC is fully supported, as is DMD master
> * LDC and older DMD's will work for simpler projects, but won't handle linking external libraries at the moment. I had a hack workaround for this before, but recently removed it when restructuring things a bit.
> * 32-bit DMD on Windows can't really be used for a C/C++/D mixed project right now because of problems I'm having with Optlink
> * VisualD generation works (tested on VS 2010 and VS 2012)
> * Makefile generation (and similar generators) work
> * Works on Windows and Linux. OS X ought to work, but is untested, as I don't have my OS X dev environment set up at the moment
> * D is listed on the CMake Qt GUI, which is nice
>
> Github: https://github.com/trentforkert/cmake
> Wiki: https://github.com/trentforkert/cmake/wiki
> Binaries: https://drive.google.com/folderview?id=0B5vzzNch4TtET09HM0NLWURKV1U&usp=drive_web#list
>
>
> As is tradition here, destroy!
>
>  - Trent

Is this ready to be posted to HN/Reddit, or still no-go?

On Tue, Apr 01, 2014 at 20:11:02 +0000, 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 using it externally (especially since getting it on the radar for 3.1 would be nice).

For example, it seems that there are new signatures that need vetting (include_directories(TEXT)), some new INTERFACE properties which need plumbed (text include directories at least, possibly DDoc stuff?), and other minor things (cmDependsD not working for older compilers last I looked, something needs to be done about the Ninja patch I made, removal of unnecessary code in the Platform/ and Compiler/ files, probably more).

--Ben

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 greater, owing to a need for the compiler to handle shared libs passed directly to it and the -deps flag, respectively. LDC will be back on the list pending it gaining support for those things.
2. The major use case of mixing C/C++/D code is still fundamentally broken with Win32 DMD because of Optlink problems my poor Linux brain has yet to sort out. This is even more problematic, since the needed GDC version doesn't work on (or at least doesn't have a build for) Windows.
3. I'm still worried about creating confusion around CMake's pending 3.0 release.

I want it to be as friction-less as possible for C/C++ & CMake users to swap out their CMake install, add a D compiler, and start using D alongside C/C++ in their projects. Right now, such an effort would most likely be met with frustration pretty quickly. That frustration will end up aimed at D, even if it should be aimed at my work on this project. That won't benefit anybody.

I've got a list of things in my head I want to be fixed/supported before publishing this too far and wide. I'll work on moving those from my head to the bug tracker tonight, so I don't forget about them.

 - Trent

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 that. I'd also rather it go through CMake vetting before HN/reddit vetting, as I feel like the former would be a lot more productive than the latter.

> For example, it seems that there are new signatures that need vetting
> (include_directories(TEXT)), some new INTERFACE properties which need
> plumbed (text include directories at least, possibly DDoc stuff?),

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 at compile time, literally putting a string of the contents of the specified file where the import() was.

> and
> other minor things (cmDependsD not working for older compilers last I
> looked,

Yeah, I'm not sure there's much I can do about that. I have to choose between scanning textually imported files as dependencies (which they are) or supporting older compilers. Granted, the Ninja dependency resolution doesn't register text imports, since I have to specify the filename in the arguments. "-deps > <DEPFILE>" could work, but we would have to ensure that it comes last on the command line. "-deps=<DEPFILE>" doesn't output all the same information as "-deps > <DEPFILE>". Same holds for GDC and LDC equivalents.

 - Trent