Re: DDT 0.11.0 released
On Friday, 20 March 2015 at 14:36:51 UTC, Dicebot wrote: I wasn't referring to the vim vs IDE holy debate. I often use IDE myself but never use interal build systems tied to IDE - mostly for portability reasons. It is good to know that your project will always be built the same way - on local development box, in packaging script, on headless CI box. Which is one of the reasons I use CMake ^_^. It ensures the build button in your IDE behaves the same as make, regardless of which box the code is built on. Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much. It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work. .dproject is exactly dub.json As I said in my response to Bruno earlier, this still requires dub for things to work, which isn't an acceptable solution. A real .dproject would not require tools outside of Eclipse/DDT to function, and would preferably be similar to .project and .cproject. I don't really understand the part about putting paths to .project though That was a misunderstanding of Eclipse internals on my part. When the basic case of completing symbols from phobos worked, I just assumed that those include directories were being written to a portable place, since I hadn't done anything special for Eclipse project generation. how it can possibly put something that is language specific there? Include directories are not language specific, at least not in CMake.
Re: DDT 0.11.0 released
On Friday, 20 March 2015 at 15:52:18 UTC, Dicebot wrote: It is _supposed_ to be the same, but not necessarily is. Bugs in CMake generators are not impossible. Of course not, but I prefer a build system that works 99.99% of the time regardless of where it is used over a build system that can only be used on one machine or software stack. And I don't understand why it is not acceptable. * Because it is not guaranteed to be there. For instance, I don't have dub on my system * Because anybody not using dub should not be required to use dub. This is dlang, not dublang * Because it is at odds with C/C++ integration, which is an H1 priority * Because I just want to tell Eclipse about the project, there is no need to involve dub * Because the user said so dub is de-factor part of standard compiler toolchain for D. No it isn't. Neither is rdmd. Nor is make part of the standard compiler toolchain for C. When CDT uses make it does so *because it was told to*. Same with ninja. VisualStudio project generation doesn't use makefiles, because it is generating a VisualStudio project. And the fact that a whole bunch of abandoned single-module D libraries use dub is irrelevant when people like me, Manu, etc are working on larger, more complicated projects and say (repeatedly!!) that dub doesn't meet our needs. It is developed as D-Programming-Language organization project and planned for eventual distribution with compiler. rdmd is already distributed with dmd. Is it now a required part of the build process for all projects? VisualD is also developed under D-Programming-Language. Is it now required as well? Why isn't DDT using a .visualdproj? Saying that is unacceptable as dependency is similar to saying that Phobos is unacceptable as dependency. I'm not saying Phobos is unacceptable, but there are those that do. However, phobos is a library, not a build tool. Apples, oranges, etc. Include directories are not language specific, at least not in CMake. Sounds like design mistake to me. There is nothing similar between include directories in C and import paths in D. It's a list of directories. Sure, the compilers might do different things with the directories, but I've never encountered any harm from there just being a single list of directories to look for includes/imports in. Even within D -J paths and -I paths need to be treated differently. My fork handles -J paths separately from -I paths: include_directories(foo) # -Ifoo include_directories(TEXT bar) # -Jbar Similarly, CMake also handles regular vs system include paths for C/C++ compilers: include_directories(SYSTEM baz) # -isystem baz However, D doesn't have a -isystem, so SYSTEM is effectively ignored when producing the flags for a D compiler.
Re: DDT 0.11.0 released
On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote: I call dub from makefile rules and feel pretty comfortable about such pattern (apart from being not-so-portable compared to raw dub). And building anything via IDE is just asking for trouble :) I use Vim myself, but I think people who use IDEs would like to, well, use IDEs. Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much. It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work.
Re: DDT 0.11.0 released
On Thursday, 19 March 2015 at 15:14:09 UTC, Bruno Medeiros wrote: On 19/03/2015 14:45, Trent Forkert wrote: It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work. DDT does support a .dproject ... it's called dub.json ! ;) I'm dead serious here though. Why would I invent my own file format to describe source folders and include/imports paths when dub.json does that already?? 1. I don't consider an XML configuration to be your own file format 2. For the very reason that started this entire conversation. Not everybody *wants* to use dub. Not everybody *can* use dub. So it doesn't make sense for DDT to force dub. It would be silly to use anything else. VisualD has done pretty well for itself. If you absolutely don't want to use DUB to build things, there are ways to disable the DUB builder, as mentioned before in this thread, and this way you'll use dub.json merely to describe the import path structure of the D project. This still requires dub for things to work, which isn't an acceptable solution. Using XML the way CDT does also allows something else: GUI configuration. Users could then adjust build parameters via a GUI the way IDE users would expect to be able to, instead of editing a configuration file for a tool they aren't even using.
Re: DDT 0.11.0 released
On Wednesday, 18 March 2015 at 21:49:17 UTC, Bruno Medeiros wrote: Why is it insufficient? You don't have to use DUB to the exclusion of everything else. Isn't the use of the preGenerateCommands (http://code.dlang.org/package-format#build-settings) enough to call these other build systems you use? You're joking, right? The only sensible way to use multiple languages in the same project is to use the same build system for them. Anything else is way too fragile and hackish. Arbitrary, contrived example (though not entirely unrealistic): * a C(++) executable needs a static D library * Said D library in turn uses a C(++) library * All three of these are built as components of the same project So now I need a weird tangled mess of build systems calling each other back and forth. Dub really doesn't pull its weight here.
Re: DDT 0.11.0 released
On Wednesday, 18 March 2015 at 21:12:11 UTC, Bruno Medeiros wrote: What kind of Eclipse projects does it generate? CDT. Anything else would prevent it from supporting multi-language projects, and thus turn it into yet another crappy monolingual NIHS tool, and thus useless for me (and Manu). If it generates CDT projects, it's not really much help as CDT doesn't understand D (duh), Nor does it need to. The project builds with either Make or Ninja, and Eclipse doesn't even care that it is building D code, and will build successfully even if you don't have DDT installed. and DDT doesn't work with CDT projects (also duh). Not sure what you mean by that. Installing DDT allows Eclipse to see *.d files (in any project, DDT, CDT or otherwise) as D files that will be opened in Eclipse's editor with syntax highlighting, completion, etc. Without DDT, Eclipse opens D files in an external editor. I just double checked, this all still works as I was expecting it to.
Re: DDT 0.11.0 released
On Tuesday, 17 March 2015 at 23:54:06 UTC, Manu wrote: On 17 March 2015 at 06:00, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 06/03/2015 17:37, Bruno Medeiros wrote: A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) A new release fixing a critical regression is out: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.1 -- Bruno Medeiros https://twitter.com/brunodomedeiros I just checked out DDT, and I noticed it seems to use DUB... _ Why this marriage? I was really hoping it would be a lot more like CDT (ie, raw and flexible). In the project configuration I just see the one DUB Options box. The comprehensive suite of build options CDT presents would be much nicer. DUB is insufficient for any of my projects, and sadly, that makes DDT insufficient for my projects too :( The problem with DUB is it's self-contained. My projects involve cross-language interaction, and the build environments can be complex. DUB can't express this. I also couldn't launch GDB and debug the example 'hello world' app under Windows. Are there more steps to make this work? Unless something has changed recently, it shouldn't require dub. Last time I checked, my CMake work[1] could still generate projects for Eclipse from a D codebase, using Makefiles or Ninja. Not that that helps if you are creating a project from an Eclipse Wizard, which I haven't done in a long time. [1] https://github.com/trentforkert/cmake
Re: CMake with D support early snapshot
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
Re: CMake with D support early snapshot
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
Re: CMake with D support early snapshot
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
Re: CMake with D support early snapshot
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
Re: CMake with D support early snapshot
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 (which isn't linked with Kitware/CMake, so PRs are unavailable…an unfortunate GitHub limitation; I've contacted support about this). I now have it working for a dummy project. I've also commented on the branch as a whole on that issue as well. --Ben As I told Ben on Github, I didn't realize CMake had a github mirror. So, I waved my magic wand and made trentforkert/cmake a github fork of Kitware/CMake so that PRs should work now. The original (non-github-fork) repo is now preserved at trentforkert/cmake_old, just in case we need it for something. - Trent
Re: CMake with D support early snapshot
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
requires me to put a special case in the C++ that I'd rather not
have.
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.
It should be noted that (AFAICT), the Ninja generator is the only
thing that even considers ${CMAKE_DEPFILE_FLAGS_lang}. All the
Makefile generators (basically everything but Ninja, VS, and
possibly XCode) use the cmDepends system.
Thoughts?
- Trent
Re: CMake with D support early snapshot
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-style depfile of the relevant sources. It then scans each of the foo (.../foo.d) : public : object (.../object.di) lines, pulling the filepaths from the () to construct the file depends.make in the correct CMakeFiles/target.dir, which contains a list of lines like: .../foo.d.o: .../foo.d .../foo.d.o: .../object.di Yeah, seems so. If we could get rid of the cmDepends* stuff, that'd be nice. I only see it included from Source/cmLocalUnixMakefileGenerator3.* which means if the Makefile learns about depfiles, we can start removing cmDepends* (yay!). I guess the IDE generators rely on IDE magic to get dependencies correct? Y'know, I didn't really know. So, I spent longer than I'd care to admit in a find|grep loop examining the source. Raw notes as I progressed are appended to the bottom of this post, but the takeaway is that there are only really four kinds of generators: * Makefiles * Ninja (Some depfile solution) * Visual Studio (maybe VisualD will help handle things for us) * XCode (absolutley no idea) Everything else is implemented on top of those. All the non-VS non-XC generators ultimately go through cmLocalUnixMakefile3 and cmDepends, or they go through Ninja. So, we'll still need to get Ninja, VS, and XCode dependency separately, but cmDepends handles the all other generator's dependency resolution. So...it looks like this is what we're aiming for: - DMD/LDC - Support make-style depfiles (optional; unlikely) - Support filtering out excess dependencies (private import, system files) (preferred) Right now I'm doing direct dependencies only, so if module foo imports std.stdio, it adds a dependency on stdio.di, but nothing else. I think we might actually want full (recursive) dependency listings though, because of how templates work. Alternatively, I can just check the module names and filter out std.* and similar. - Ninja - dmd depfile support (preferred; no comment from martine yet) - CMake - Add depfile support to Make (preferred) - Add dmd - make depfile translator (likely necessary[2]) Like I said above, that's what I'm doing in cmDependsD at the moment. Since Ninja, VS and XCode all do their own thing, I think its fine to leave that translator inside cmDependsD. --Ben [1]http://stackoverflow.com/a/16969086 [2]The dmd-depfile format probably won't fly with make upstream since make-depfiles aren't actually a thing with make, but gcc. Whatever CMake does with their depends.make (I didn't go that deep), it works on all of the different Makefile generators CMake supports. - Trent What follows is my notes as I sorted things out: The method cmLocalUnixMakefileGenerator3::WriteDependLanguageInfo() calls into the cmDepends* system. This method is called by cmMakefileTargetGenerator::WriteTargetDependRules(). This in turn is called by WriteRuleFiles in cmMakefileExecutableTargetGenerator and cmMakefileLibraryTargetGenerator, which is called by cmLocalUnixMakefileGenerator3::Generate(). The cmLUMG3 will be set as the local generator for every cmGlobal*Generator except for Kdevelop, Ninja, VisualStudio and XCode. Upon inspection: * Kdevelop uses the Unix Makefile generator behind the scenes * Ninja does its own thing * VisualStudio does its own thing * XCode appears to do its own thing There are also cmExtra*Generators, for completeness, I'll inspect them too. * CodeBlocks: uses another Makefile generator * CodeLight: uses a Makefile generator or Ninja * Eclipse: uses a Makefile generator or Ninja * Kate: Makefile or Ninja * Sublime: Makefile or Ninja
Re: CMake with D support early snapshot
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 context of D. No, I meant, using the DEPFLAGS during the make build (like ninja does) rather than doing it at configure time. 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... I've also tested with a simple C project (to confirm I no D-related bugs get in the way) that depend.make is generated and updated at build time. After building, I went and updated my C file to point to a new header it hadn't touched before, re-ran make (not cmake), and checked that depend.make listed now the header as a dependency (it did). To be extra sure, I reverted the change to the C code, and ran make again. depend.make was updated to remove the header dependency. The reason cmDependsD didn't update deps at build-time when I tried appears to be a matter of implementing another method I haven't got to yet. You're right that examine_d_source only worked at configure time, but cmDepends works at build time. Ninja is fine with the 'deps = dmd' solution. I will go with that then. VS will need VisualD I imagine (probably fine to require) It absolutely does. and XCode will need someone who cares enough to look into it (not me...) ;) . A cursory search finds a[1] few[2] solutions[3], but that's about the limit of my attention span for XCode+D right now. Yeah, I'm set up to work on Windows and Linux at the moment. Despite using a Macbook, I almost never touch OS X ^_^. Recursive public (non-static?) imports is the proper, minimal way to do it; you may be getting an import implicitly via another forwarding module. Like I said above, that's what I'm doing in cmDependsD at the moment. Since Ninja, VS and XCode all do their own thing, I think its fine to leave that translator inside cmDependsD. I think I was unclear: I'd like to see the dependency resolution done at build time, not configure time. That's why there'd be something like: %.o: %.d %.d: %.dmd.d -cmake -DINPUT=$ -DOUTPUT=$ -P cmake_root/CMakeDMDToMakeDeps.cmake -include $(wildcard *.d) I can do something like that if its needed, I think. cmDependsFortran appears to generate dependency rules that call CMake, and 'cmake -E cmake_depends ...' is the command that is actually used to generate a depend.make. But, as I said above, cmDepends is a build-time thing. It's more obtuse about it than the Ninja generator is, but it is still build-time. My understanding (without looking): the extra generators basically do some scaffolding to write IDE files which just tell the IDE how to run the internal generator, possibly with a list of targets, sources, and whatnot for those which can't manually inspect the build files themselves. Correct. - Trent
CMake with D support early snapshot
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=0B5vzzNch4TtET09HM0NLWURKV1Uusp=drive_web#list As is tradition here, destroy! - Trent
