www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DDT 0.11.0 released

reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
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)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 06 2015
next sibling parent "NCrashed" <NCrashed gmail.com> writes:
On Friday, 6 March 2015 at 17:37:51 UTC, 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)


Thank you! DDT is actually the most convenient D IDE at the 
moment.

P.S. Could I request a feature? a better support for dub 
subconfigurations (yep, I know, if I want something, then it's my 
fault that isn't implemented yet).
Mar 06 2015
prev sibling next sibling parent reply "wobbles" <grogan.colin gmail.com> writes:
On Friday, 6 March 2015 at 17:37:51 UTC, 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)


This is great, thank you!

Just to let you know, in release notice there is the text
"It is recommended that Recommend re-create project."
Im guessing it is meant to be:
"It is recommended to re-create you're project."
Mar 06 2015
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 06/03/2015 18:48, wobbles wrote:

 On Friday, 6 March 2015 at 17:37:51 UTC, 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)


 This is great, thank you!

 Just to let you know, in release notice there is the text
 "It is recommended that Recommend re-create project."
 Im guessing it is meant to be:
 "It is recommended to re-create you're project."


Yup, thx, fixed that.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 06 2015
prev sibling next sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
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)


Also fixed that this 0.11.0 version was being reported as 0.10.4 still.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 06 2015
prev sibling next sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
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
Mar 16 2015
parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
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?
Mar 17 2015
next sibling parent reply "Trent Forkert" <trentforkert gmail.com> writes:
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
Mar 17 2015
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 18/03/2015 00:12, Trent Forkert wrote:

 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


What kind of Eclipse projects does it generate? If it generates CDT 
projects, it's not really much help as CDT doesn't understand D (duh), 
and DDT doesn't work with CDT projects (also duh).

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 18 2015
next sibling parent reply "Trent Forkert" <trentforkert gmail.com> writes:
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.
Mar 18 2015
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 18/03/2015 22:09, Trent Forkert wrote:

 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.


When I said "it's not really much help", I didn't mean for building: I 
meant for code completion and other semantic functionality. A CDT 
project description means nothing for DDT, and as such, code completion 
and other semantic functionality won't work properly (you will get code 
completion for the standard library, and for symbols of the .d file you 
opened, but any other imports/modules will not be found).


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 19 2015
prev sibling next sibling parent Ben Boeckel via Digitalmars-d-announce writes:
On Wed, Mar 18, 2015 at 21:12:07 +0000, Bruno Medeiros via
Digitalmars-d-announce wrote:

 What kind of Eclipse projects does it generate? If it generates CDT 
 projects, it's not really much help as CDT doesn't understand D (duh), 
 and DDT doesn't work with CDT projects (also duh).


It should add DDT support[1] for D projects.

--Ben

[1]https://github.com/trentforkert/cmake/blob/d_support3/Source/cmExtraEclipseCDT4Generator.cxx#L70-L73
Mar 18 2015
prev sibling parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 19 March 2015 at 07:12, Bruno Medeiros via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On 18/03/2015 00:12, Trent Forkert wrote:

 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



 What kind of Eclipse projects does it generate? If it generates CDT
 projects, it's not really much help as CDT doesn't understand D (duh),




 and DDT doesn't work with CDT projects (also duh).


Why is that 'duh'? I would expect nothing less than for DDT and CDT to
interact comprehensively.
VisualD and Mono-D interact extensively with the existing C/C++
toolsets present on those platforms.
Mar 19 2015
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 20/03/2015 04:12, Manu via Digitalmars-d-announce wrote:

 On 19 March 2015 at 07:12, Bruno Medeiros via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 On 18/03/2015 00:12, Trent Forkert wrote:

 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



 What kind of Eclipse projects does it generate? If it generates CDT
 projects, it's not really much help as CDT doesn't understand D (duh),




 and DDT doesn't work with CDT projects (also duh).


 Why is that 'duh'? I would expect nothing less than for DDT and CDT to
 interact comprehensively.


Fair enough on that last 'duh', it could have been that DDT integrated 
with CDT.


 VisualD and Mono-D interact extensively with the existing C/C++
 toolsets present on those platforms.


Do they now? I'm inclined to try them out again because I'm a bit 
skeptical of that comment, as least in how it applies to this discussion.
For example, does Mono-D allow to seamlessly create a crossplatform 
"solution" with a D project interacting with a C project (and/or the 
opposite). And what exactly "seamlessly" means here, what is offered in 
Mono-D that couldn't be done in DDT?


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 23 2015
parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 23 March 2015 at 22:39, Bruno Medeiros via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On 20/03/2015 04:12, Manu via Digitalmars-d-announce wrote:

 On 19 March 2015 at 07:12, Bruno Medeiros via Digitalmars-d-announce

 <digitalmars-d-announce puremagic.com> wrote:

 On 18/03/2015 00:12, Trent Forkert wrote:

 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




 What kind of Eclipse projects does it generate? If it generates CDT
 projects, it's not really much help as CDT doesn't understand D (duh),





 and DDT doesn't work with CDT projects (also duh).



 Why is that 'duh'? I would expect nothing less than for DDT and CDT to
 interact comprehensively.



 Fair enough on that last 'duh', it could have been that DDT integrated with
 CDT.


 VisualD and Mono-D interact extensively with the existing C/C++
 toolsets present on those platforms.


 Do they now? I'm inclined to try them out again because I'm a bit skeptical
 of that comment, as least in how it applies to this discussion.


I use those IDE's every day, and all my projects are C/C++ engine/ibs
and D frontend code.
In Visual-D you can even press F12 (go to definition) on an extern(C)
symbol in your D code, and it will jump to the .cpp file where it's
defined.



 For example, does Mono-D allow to seamlessly create a crossplatform
 "solution" with a D project interacting with a C project (and/or the
 opposite).


Absolutely, if it didn't, it wouldn't be useful (to me).


 And what exactly "seamlessly" means here, what is offered in
 Mono-D that couldn't be done in DDT?


Automatic linking between sibling libs within a solution, referencing
of symbols between the languages/projects, automatic rebuild
dependencies between sibling projects.
I'm sure it could all be done in DDT. I'm just saying that as an
end-user I would expect that level of interoperation with CDT and no
less.
I haven't tested those things, they may already work.
Mar 23 2015
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 24/03/2015 02:22, Manu via Digitalmars-d-announce wrote:

 On 23 March 2015 at 22:39, Bruno Medeiros via Digitalmars-d-announce
 In Visual-D you can even press F12 (go to definition) on an extern(C)
 symbol in your D code, and it will jump to the .cpp file where it's
 defined.


That's quite nice.


 And what exactly "seamlessly" means here, what is offered in
 Mono-D that couldn't be done in DDT?


 Automatic linking between sibling libs within a solution, referencing
 of symbols between the languages/projects, automatic rebuild
 dependencies between sibling projects.
 I'm sure it could all be done in DDT. I'm just saying that as an
 end-user I would expect that level of interoperation with CDT and no
 less.
 I haven't tested those things, they may already work.


Just FYI:
"referencing of symbols between the languages/projects" definitely 
doesn't work at all.
The rest, "Automatic linking between sibling libs within a solution", " 
automatic rebuild dependencies between sibling projects", etc., that 
won't work out of the box, but can be made to work if you go configure 
Eclipse options, and build system configuration. Requires some work, it 
won't be seamless.

I'm gonna me straight up with you about DDT: With work, probably a lot 
could could be achieved in terms of CDT C/C++ integration. But, 
personally, I became interested in the D world to completely escape the 
C/C++ one. I don't use C/C++ professionally or on a hobby basis. That 
means doing CDT integration (other than trivial stuff) is low priority 
for me - even though I fully agree that better D and C/C++ toolchain 
integration is very important for D's success, if not vital.
And "low priority", given all the stuff I have planned in the DDT 
(&siblings) roadmap, effectively means: "not gonna get done". Unless 
someone else wants to work on that (that would be welcome of course).

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 24 2015
prev sibling next sibling parent "albatroz" <rmcjustino gmail.com> writes:
Just go to project Properties, Builders, de-select DUB Build and 
add any another build option or script you need.

On Tuesday, 17 March 2015 at 23:54:06 UTC, Manu wrote:


 I just checked out DDT, and I noticed it seems to use DUB... >_<
Mar 18 2015
prev sibling next sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 17/03/2015 23:45, Manu via Digitalmars-d-announce wrote:

 I also couldn't launch GDB and debug the example 'hello world' app
 under Windows. Are there more steps to make this work?


If you're using DMD, that simply doesn't work at all. GDB doesn't 
understand any of the debug formats DMD outputs (COFF/MSVC or OMF), and 
it likely never will.

GDC for Windows is not maintained.

As LDC for Windows, I haven't tried it recently. Last time I tried it, 
debugging support wasn't working ( 
http://forum.dlang.org/post/qsttkqzbtnhyrogekppn forum.dlang.org ). 
However may be that has changed recently? I dunno about LDC itself, but 
I've tried the Rust compiler for Windows, and although a bit buggy, 
basic debugging support was working: 
https://raw.githubusercontent.com/RustDT/RustDT/master/documentation/screenshots/sample_debug.png
So the same should be possible for LDC as well!

Note: I try to collate this information in 
http://wiki.dlang.org/Debuggers , although perhaps "Debugging support" 
should listed by platform, instead of "by compiler".


If you absolutely must use DMD/MSVC toolchains, well there might be some 
hope int the future, since work is being done on LLDB such as to be able 
to debug MSVC executables: 
http://blog.llvm.org/2015/01/lldb-is-coming-to-windows.html
(LLDB has an interface emulating GDB, and as such should integrate with 
Eclipse and other GDB UI frontends)


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 18 2015
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 17/03/2015 23:45, Manu via Digitalmars-d-announce wrote:

 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.


It makes no sense for DDT to use anything else than DUB.

At a minimum, DDT needs a way to describe projects: the source files 
that are part of the project, and which other projects are dependencies 
of said project.
Other aspects of a projects that are good to be able to describe are: 
which build configurations the project supports, which executables are 
produced (if any), etc..

Now the reason DUB is used is that it's a bad paradigm for this 
description mechanism to be Eclipse/DDT specific. It's unequivocally 
much better to be Eclipse-independent, such that other tools (not just 
other IDEs, but even other command-line analysis tools) can understand D 
projects/bundles/packages just as well as DDT. It also saved me a lot of 
work. If I had to develop my own format to describe all these aspects, 
it would not be as good as DUB's, guaranteed! I reckon this is true for 
any other D IDE out there.



 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.


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?

The only problem so far is that DDT doesn't support mutiple build 
configurations, but that's a DDT limitation, not a DUB one.

You can also disable the DUB builder in DDT, as albatroz mentioned, 
however that isn't ideal since you won't get the compiler build errors 
reported back to Eclipse (DDT only has parsing errors built-in, other 
errors come externally, from the compiler.).

There should be a way to integrate DUB with your build environment.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 18 2015
next sibling parent reply "Trent Forkert" <trentforkert gmail.com> writes:
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.
Mar 18 2015
next sibling parent Ben Boeckel via Digitalmars-d-announce writes:
On Wed, Mar 18, 2015 at 22:32:05 +0000, Trent Forkert via
Digitalmars-d-announce wrote:

 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.


FWIW, no language-specific build system I've ever come across does
anything better than "meh" (and that's just one; the rest are basically
"nope, can't do it") for support outside of their language or compiling
C code against the core runtime/libraries. Then toss in cross-compiling
of the C bits and all of them just fall apart. You really need something
like Make, Ninja, or another generic build tool at the bottom to do
things properly with how different dependencies can be constructed in a
complex codebase; you can't really bake all of the knowledge required
for the general cases in every language's tools.

--Ben
Mar 18 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 18 March 2015 at 22:32:06 UTC, Trent Forkert wrote:

 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.


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 :)

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.
Mar 19 2015
next sibling parent reply "Trent Forkert" <trentforkert gmail.com> writes:
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.
Mar 19 2015
next sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 19/03/2015 14:45, Trent Forkert wrote:

 On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote:

 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.




Exactly.


 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?? It would be silly to use anything else. 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.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 19 2015
next sibling parent reply "Trent Forkert" <trentforkert gmail.com> writes:
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.
Mar 19 2015
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 19/03/2015 15:55, Trent Forkert wrote:

 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"


Err.., but it is. XML is just syntax, you still have the semantics of 
what that data means to be defined. Just as learning XML doesn't mean 
you know how to properly read/write HTML5! (Maybe there is a better term 
than "file format", but regardless I think my comment was clear.


 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.


At the time of this message of yours, you didn't offer any concrete, 
*technical* reasons of why dub shouldn't be used. Saying one doesn't 
*want* to use dub is not a valid reason at all. Saying you can't, 
without saying why, is no valid reason either.


 It would be silly to use anything else.


 VisualD has done pretty well for itself.


And is that a full-featured integration, or does it have significant 
limitations? You see, before DUB was, DDT did have it's own `.dproject` 
of sorts ('.buildpath' for those who remember), and it's own basic 
builder. But that integration was very basic and had severe limitations.

What I'm wondering is how good the VisualD on is then. Unfortunately I 
can't easily check it out myself because if the point here is to check 
C/C++ I'd probably have to install the commercial version of Visual 
Studio to try it out.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 23 2015
parent reply Ben Boeckel via Digitalmars-d-announce writes:
On Mon, Mar 23, 2015 at 12:51:36 +0000, Bruno Medeiros via
Digitalmars-d-announce wrote:

 At the time of this message of yours, you didn't offer any concrete, 
 *technical* reasons of why dub shouldn't be used. Saying one doesn't 
 *want* to use dub is not a valid reason at all. Saying you can't, 
 without saying why, is no valid reason either.


Can dub build multiple libraries in the same project? Different flags to
different source files? Running a Python script to generate D code?


 And is that a full-featured integration, or does it have significant 
 limitations? You see, before DUB was, DDT did have it's own `.dproject` 
 of sorts ('.buildpath' for those who remember), and it's own basic 
 builder. But that integration was very basic and had severe limitations.


With CMake, you don't need to do the build steps in DDT; Eclipse already
knows how to run an external build tool just fine.


 What I'm wondering is how good the VisualD on is then. Unfortunately I 
 can't easily check it out myself because if the point here is to check 
 C/C++ I'd probably have to install the commercial version of Visual 
 Studio to try it out.


VS2013 Community Edition should work.

--Ben
Mar 23 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 23 March 2015 at 13:40:04 UTC, Ben Boeckel wrote:

 Different flags to
 different source files?


If you mean separate compilation with different flags per module 
and linking into same binary - it is pretty much illegal in D and 
can only be done at own risk. I don't know if it is mentioned 
anyway on dlang.org but that is inevitable side-effect of how 
symbol emitting works.
Mar 23 2015
parent reply Ben Boeckel via Digitalmars-d-announce writes:
On Mon, Mar 23, 2015 at 14:04:30 +0000, Dicebot via Digitalmars-d-announce
wrote:

 If you mean separate compilation with different flags per module 
 and linking into same binary - it is pretty much illegal in D and 
 can only be done at own risk. I don't know if it is mentioned 
 anyway on dlang.org but that is inevitable side-effect of how 
 symbol emitting works.


Makes sense for -fversion and the like (it would be nice if libraries
exported the list of version symbols they had since it is basically
ABI...), but not necessarily for things like SSE support where you want
to do runtime detection and run the fastest version based on the running
processor. You might need to compile foo.bar.sse3 and foo.bar.sse4 with
different compiler flags.

--Ben
Mar 23 2015
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 23 March 2015 at 15:30:43 UTC, Ben Boeckel wrote:

 On Mon, Mar 23, 2015 at 14:04:30 +0000, Dicebot via 
 Digitalmars-d-announce wrote:

 If you mean separate compilation with different flags per 
 module and linking into same binary - it is pretty much 
 illegal in D and can only be done at own risk. I don't know if 
 it is mentioned anyway on dlang.org but that is inevitable 
 side-effect of how symbol emitting works.


 Makes sense for -fversion and the like (it would be nice if 
 libraries
 exported the list of version symbols they had since it is 
 basically
 ABI...), but not necessarily for things like SSE support where 
 you want
 to do runtime detection and run the fastest version based on 
 the running
 processor. You might need to compile foo.bar.sse3 and 
 foo.bar.sse4 with
 different compiler flags.


I'd suggest to build such modules as separate static libraries 
(which is possible within dub). Risk remains but it at least 
becomes obvious for other developers that this needs care. Also 
parallel build of several static libraries should be generally 
faster than parallel builds of all modules 1-by-1 (overhead of 
single file compilation is huge because of redundant import 
analysis)

Also don't forget that there are plenty of implicit versions that 
get added from compiler flags (like D_NoBoundsChecks or D_PIC).
Mar 23 2015
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 23/03/2015 13:39, Ben Boeckel via Digitalmars-d-announce wrote:

 On Mon, Mar 23, 2015 at 12:51:36 +0000, Bruno Medeiros via
Digitalmars-d-announce wrote:

 At the time of this message of yours, you didn't offer any concrete,
 *technical* reasons of why dub shouldn't be used. Saying one doesn't
 *want* to use dub is not a valid reason at all. Saying you can't,
 without saying why, is no valid reason either.






 Can dub build multiple libraries in the same project?


Yes - use DUB sub-packages.


 Different flags to different source files?


What dicebot said.
That looks like an invalid, abstraction-breaking thing to do


 Running a Python script to generate D code?


Yes, in DUB you can run arbitrary external commands before and after the 
D sources compilation.


 And is that a full-featured integration, or does it have significant
 limitations? You see, before DUB was, DDT did have it's own `.dproject`
 of sorts ('.buildpath' for those who remember), and it's own basic
 builder. But that integration was very basic and had severe limitations.


 With CMake, you don't need to do the build steps in DDT; Eclipse already
 knows how to run an external build tool just fine.


 What I'm wondering is how good the VisualD on is then. Unfortunately I
 can't easily check it out myself because if the point here is to check
 C/C++ I'd probably have to install the commercial version of Visual
 Studio to try it out.


 VS2013 Community Edition should work.

 --Ben


I thought about that - VS2013 Community Edition -, but it looks huge and 
I don't want to install a bunch of library and stuff on my computer just 
to try VisualD out. I'd do it in a virtual machine though, as its 
worthwhile to check it out. But it will just have to wait until I get 
around to it, I don't have a spare Windows VM or installation at the moment.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 23 2015
parent reply Ben Boeckel via Digitalmars-d-announce writes:
On Mon, Mar 23, 2015 at 14:25:22 +0000, Bruno Medeiros via
Digitalmars-d-announce wrote:

 Yes - use DUB sub-packages.


Ah, had missed this.


 Different flags to different source files?


 
 What dicebot said.
 That looks like an invalid, abstraction-breaking thing to do


Not all flags are -fversion or -I flags.


 Running a Python script to generate D code?


 
 Yes, in DUB you can run arbitrary external commands before and after the 
 D sources compilation.


But not in between? Basically, can you have a tool written in D built
with the project and then used to generate code in the same project?

--Ben
Mar 23 2015
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 23/03/2015 15:35, Ben Boeckel via Digitalmars-d-announce wrote:

 Running a Python script to generate D code?


 Yes, in DUB you can run arbitrary external commands before and after the
 D sources compilation.


 But not in between? Basically, can you have a tool written in D built
 with the project and then used to generate code in the same project?

 --Ben


That should be possible if you split it into two bundles or so, if I 
understood that case correctly. The external commands run before and 
after a compilation of a bundle (known in DUB as "package"). So you 
could have:

1. bundleA - pre external commands
2. bundleA - D sources compilation
3. bundleA - post external commands
4. bundleB - pre external commands
5. bundleB - D sources compilation
and so on.. (if bundleA is set as a dependency of bundleB)


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 24 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/03/2015 2:24 a.m., Bruno Medeiros wrote:

 On 23/03/2015 15:35, Ben Boeckel via Digitalmars-d-announce wrote:

 Running a Python script to generate D code?


 Yes, in DUB you can run arbitrary external commands before and after the
 D sources compilation.


 But not in between? Basically, can you have a tool written in D built
 with the project and then used to generate code in the same project?

 --Ben


 That should be possible if you split it into two bundles or so, if I
 understood that case correctly. The external commands run before and
 after a compilation of a bundle (known in DUB as "package"). So you
 could have:

 1. bundleA - pre external commands
 2. bundleA - D sources compilation
 3. bundleA - post external commands
 4. bundleB - pre external commands
 5. bundleB - D sources compilation
 and so on.. (if bundleA is set as a dependency of bundleB)


Actually I was thinking along the lines of using sub packages to do this.

package:
   depends on subPackage2
subPackage1:
   pre: do stuff
   compile D
   post: do stuff
subPackage2:
   depends on subPackage1
   pre: do stuff
   compile D
   post: do stuff

Of course you could chain this as long as you want.
Mar 24 2015
prev sibling parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 20 March 2015 at 01:14, Bruno Medeiros via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On 19/03/2015 14:45, Trent Forkert wrote:

 On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote:

 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.




 Exactly.


 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?? It would be silly to use anything else. 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.


I would imagine that if you had complete control over the project
description and build process, it would be much easier to integrate
with other components in Eclipse?
Of course, I have no idea whether that's true or not. But I will
hazard a guess that using dub in this way must make it harder for you
to interact with CDT/java tools than otherwise?

It would also be really nice to have a UI with tick boxes and select
boxes for all the relevant build settings like CDT.
Mar 19 2015
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 20/03/2015 05:30, Manu via Digitalmars-d-announce wrote:

 On 20 March 2015 at 01:14, Bruno Medeiros via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 On 19/03/2015 14:45, Trent Forkert wrote:

 On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote:

 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.




 Exactly.


 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?? It would be silly to use anything else. 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.


 I would imagine that if you had complete control over the project
 description and build process, it would be much easier to integrate
 with other components in Eclipse?
 Of course, I have no idea whether that's true or not. But I will
 hazard a guess that using dub in this way must make it harder for you
 to interact with CDT/java tools than otherwise?


There's no plans ATM to integrate with CDT itself. (I don't even know 
what integration with java tools would mean here) Even for CDT, I don't 
see what much would there be to integrate, other than the build system.


 It would also be really nice to have a UI with tick boxes and select
 boxes for all the relevant build settings like CDT.


Yeah, true. Even if using DUB, it would be nice to have UI to control 
the settings in dub.json, but that's a fair amount of work for little 
gain, so down in the priority list.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 23 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-03-23 13:54, Bruno Medeiros wrote:


 There's no plans ATM to integrate with CDT itself. (I don't even know
 what integration with java tools would mean here) Even for CDT, I don't
 see what much would there be to integrate, other than the build system.


I would guess he means using C(++) files and D files in the same project 
and the build system would just work.

-- 
/Jacob Carlborg
Mar 23 2015
parent reply Ben Boeckel via Digitalmars-d-announce writes:
On Mon, Mar 23, 2015 at 21:14:31 +0100, Jacob Carlborg via
Digitalmars-d-announce wrote:

 On 2015-03-23 13:54, Bruno Medeiros wrote:

 There's no plans ATM to integrate with CDT itself. (I don't even know
 what integration with java tools would mean here) Even for CDT, I don't
 see what much would there be to integrate, other than the build system.


 
 I would guess he means using C(++) files and D files in the same project 
 and the build system would just work.



From what I understand[1] of Eclipse (which I admit isn't much from a


user's PoV), it supports "natures" to be loaded which provide
functionality. Now I have no idea how much work this is, but it would be
nice to have a nature for D support (syntax highlighting, completion,
etc.). If it includes dub, great, but it might be worth it to have a
separate nature for that. CMake (and other theoretical tools) would then
just add the D support nature to handle the D files and use the existing
build support. Projects created through DDT itself could add the dub
nature by default (FWIW, I don't think CDT generates CMake-based
projects out of the box either).

Basically, make DDT suitable for using it with other projects which
don't use dub because it doesn't suit the upstream project whether it be
because the project is more than some D code, YAML is preferred to JSON
or whatever.

Take my gunroar[2] repo for example. It's mainly D code, but there is
some C and Java in the src/android directory. If one were working in
Eclipse with it, it would be nice to support using CDT features for the
C code, the native Java support for the Java code, DDT for the D code,
and the build button to put it all together.

--Ben

[1]This is based on my experience where enabling the Android bits in an
Eclipse project generated by CMake is to allow users to add natures to
the generated .project file using the ECLIPSE_EXTRA_NATURES global
property.
[2]https://github.com/mathstuf/abagames-gunroar
Mar 23 2015
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 23/03/2015 23:01, Ben Boeckel via Digitalmars-d-announce wrote:

 On Mon, Mar 23, 2015 at 21:14:31 +0100, Jacob Carlborg via
Digitalmars-d-announce wrote:

 On 2015-03-23 13:54, Bruno Medeiros wrote:

 There's no plans ATM to integrate with CDT itself. (I don't even know
 what integration with java tools would mean here) Even for CDT, I don't
 see what much would there be to integrate, other than the build system.


 I would guess he means using C(++) files and D files in the same project
 and the build system would just work.



From what I understand[1] of Eclipse (which I admit isn't much from a


 user's PoV), it supports "natures" to be loaded which provide
 functionality. Now I have no idea how much work this is, but it would be
 nice to have a nature for D support (syntax highlighting, completion,
 etc.). If it includes dub, great, but it might be worth it to have a
 separate nature for that. CMake (and other theoretical tools) would then
 just add the D support nature to handle the D files and use the existing
 build support. Projects created through DDT itself could add the dub
 nature by default (FWIW, I don't think CDT generates CMake-based
 projects out of the box either).

 Basically, make DDT suitable for using it with other projects which
 don't use dub because it doesn't suit the upstream project whether it be
 because the project is more than some D code, YAML is preferred to JSON
 or whatever.

 Take my gunroar[2] repo for example. It's mainly D code, but there is
 some C and Java in the src/android directory. If one were working in
 Eclipse with it, it would be nice to support using CDT features for the
 C code, the native Java support for the Java code, DDT for the D code,
 and the build button to put it all together.

 --Ben

 [1]This is based on my experience where enabling the Android bits in an
 Eclipse project generated by CMake is to allow users to add natures to
 the generated .project file using the ECLIPSE_EXTRA_NATURES global
 property.
 [2]https://github.com/mathstuf/abagames-gunroar


Yes, there is a D nature for Eclipse's .project:
org.dsource.ddt.ide.core.nature
Curiously though, a few DDT features will work fine without that nature, 
namely semantic features (code completion, go to definition, etc.). They 
even work with external files (files not in an Eclipse project), as long 
as they are part of a DUB bundle (known in DUB as a "package").

This is because, for example, when invoking code completion on a D 
source, DDT will try to find a "dub.json" file in the tree of parent 
dirs of the D file. Once it finds it, it will analyze the source 
structure of that bundle and all its dependency bundles (using `dub 
describe`, and then code completion will have all module information 
correctly available. And the caching of the semantic engine will still 
work just fine. :)


As for not using DUB. Hum, I could add feature of a flag to a project 
options to prevent it from using DUB (the executable). This way the DUB 
build would be a no-op, and `dub describe` would not be run either. You 
would still have to use the dub.json file to describe source folders 
though. (Again there's no sense in making a new format to describe this)

As for your gunroar example. I don't know how CMake generates an Eclipse 
project, but that scenario that sounds like it should have multiple 
Eclipse projects generated. (One for D code, one for C bits, another for 
Java bits) Trying to shove everything in one project wont work properly. 
(The directory structure of gunroar might have to be changed a bit to 
accommodate that though)

An Eclipse project is a build "unit", and is not the equivalent of a 
VisualStudio solution. An Eclipse workspace is much more akin to a VS 
solution.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 24 2015
prev sibling next sibling parent Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 20 March 2015 at 00:45, Trent Forkert via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 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.


Precisely, I was expecting a .dproject file to appear, but it didn't.
I also maintain the D (and Eclipse) support for premake (like cmake),
but I can't support D in Eclipse like C/C++ as it is.
Mar 19 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 19 March 2015 at 14:45:08 UTC, Trent Forkert wrote:

 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.


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.


 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
I don't really understand the part about putting paths to 
.project though - how it can possibly put something that is 
language specific there?
Mar 20 2015
parent reply "Trent Forkert" <trentforkert gmail.com> writes:
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.
Mar 20 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 20 March 2015 at 15:47:09 UTC, Trent Forkert wrote:

 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.


It is _supposed_ to be the same, but not necessarily is. Bugs in 
CMake generators are not impossible.


 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.


And I don't understand why it is not acceptable. dub is de-factor 
part of standard compiler toolchain for D. It is developed as 
D-Programming-Language organization project and planned for 
eventual distribution with compiler. Saying that is unacceptable 
as dependency is similar to saying that Phobos is unacceptable as 
dependency.


 how it can possibly put something that is language specific 
 there?


 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. Even 
within D -J paths and -I paths need to be treated differently.
Mar 20 2015
parent reply "Trent Forkert" <trentforkert gmail.com> writes:
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:




Similarly, CMake also handles regular vs system include paths for 
C/C++ compilers:



However, D doesn't have a -isystem, so SYSTEM is effectively 
ignored when producing the flags for a D compiler.
Mar 20 2015
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 20/03/2015 18:07, Trent Forkert wrote:

 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


That's the lamest reason ever. Why is that an issue? Just install it if 
it is not installed. To me, that's akin to saying DDT shouldn't have a 
requirement of the Java VM!


   * Because anybody not using dub should not be required to use dub.
 This is dlang, not dublang
   * Because I just want to tell Eclipse about the project, there is no
 need to involve dub
   * Because the user said so


These are basically all the same reason: "me no want to use dub!". Well, 
you're free not to use DDT either!

Seriously, I don't understand the *gripe* here: DUB offers a service, a 
functionality, that is not offered elsewhere (for D at least): a package 
management system, for source packages. And this is an important 
functionality for language ecosystems, because it is so damn useful!! 
That's why nearly all modern language have a source-package manager 
(Rust - Cargo, Ruby - rpm, Go - `go get/install`, Java - Maven/OSGi), 
all of them integrated with a build tool.
I hope your experience/mindset has not been too tainted with archaic 
C/C++ paradigms that you fail to see this.

D actually lags behind these languages in that DUB is not an official 
part of the language/toolchain. Although from what I recall there are 
plans to make DUB included as part of the DMD installation, so that 
would change.


   * Because it is at odds with C/C++ integration, which is an H1 priority


This is the only reason with some credence. However, *not using dub* 
doesn't makes DDT automatically integrate with C/C++, nor doesn't it 
even necessarily bring it any closer to that. A fair amount of work 
would still need to be done to properly support this scenario, I suspect.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 23 2015
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 19/03/2015 11:18, Dicebot wrote:

 On Wednesday, 18 March 2015 at 22:32:06 UTC, Trent Forkert wrote:

 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.


 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 :)


Indeed, I reckon in these more complex examples, you'd call DUB from 
make/cmake/whatever. DUB would be in charge of building the D library 
aspect/component of that whole project. I don't see why this would not 
be possible, or otherwise why it would be a tangled messed.

It might force to think of your build components in a more 
structured/componentized way, instead of the paradigm of building on a 
file by file basis, the `make` way. (I've only used make though, not 
cmake, so dunno how much this comment applies to the later)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 19 2015
next sibling parent reply Ben Boeckel via Digitalmars-d-announce writes:
On Thu, Mar 19, 2015 at 15:31:49 +0000, Bruno Medeiros via
Digitalmars-d-announce wrote:

 Indeed, I reckon in these more complex examples, you'd call DUB from 
 make/cmake/whatever. DUB would be in charge of building the D library 
 aspect/component of that whole project. I don't see why this would not 
 be possible, or otherwise why it would be a tangled messed.


If dub needs things built earlier and then the D code is used by CMake,
dependency tracking becomes very manual; it's better to have one tool
know the entire build structure here.


 It might force to think of your build components in a more 
 structured/componentized way, instead of the paradigm of building on a 
 file by file basis, the `make` way. (I've only used make though, not 
 cmake, so dunno how much this comment applies to the later)


Building file-at-a-time is, for developers, on the whole faster than
"unity" builds because you can parallelize it and only have to build
what changed.

CMake only really works with .d -> .o rules (Java support bends this
AFAIK due to restrictions in javac, but I vastly prefer -j8 over a
single invokation).

--Ben
Mar 19 2015
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 19/03/2015 16:02, Ben Boeckel via Digitalmars-d-announce wrote:

 It might force to think of your build components in a more

structured/componentized way, instead of the paradigm of building on a
file by file basis, the `make` way. (I've only used make though, not
cmake, so dunno how much this comment applies to the later)




 Building file-at-a-time is, for developers, on the whole faster than
 "unity" builds because you can parallelize it and only have to build
 what changed.

 CMake only really works with .d -> .o rules (Java support bends this
 AFAIK due to restrictions in javac, but I vastly prefer -j8 over a
 single invokation).


I think the issue of speed and parallellization is an orthogonal one:

The build components should be structured in properly defined, 
self-contained, versioned libraries/bundles(*) - that can be built, and 
auto-tested on their own (obviously using the dependencies they require 
too). That should be the primary (top level) build unit of a build system.

But, the way you build each bundle/component, is still up to the build 
system. You can build it on file-by-file sequentially, or parallelized, etc.

I'm not familiar with CMake, so I don't know if it has any concept 
similar to this, but I suspect not.


*: AKA "packages" in DUB and Ruby, "crates" in Rust.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 23 2015
prev sibling parent Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 20 March 2015 at 01:31, Bruno Medeiros via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On 19/03/2015 11:18, Dicebot wrote:

 On Wednesday, 18 March 2015 at 22:32:06 UTC, Trent Forkert wrote:

 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.



 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 :)


 Indeed, I reckon in these more complex examples, you'd call DUB from
 make/cmake/whatever. DUB would be in charge of building the D library
 aspect/component of that whole project. I don't see why this would not be
 possible, or otherwise why it would be a tangled messed.


Pushing variables, lib paths, include paths, etc around immediately
comes to mind.



 It might force to think of your build components in a more
 structured/componentized way, instead of the paradigm of building on a file
 by file basis, the `make` way. (I've only used make though, not cmake, so
 dunno how much this comment applies to the later)


In premake, D projects are emit as a single invocation of the compiler
given all source files at once, and this works seamlessly with C/C++
projects which are done in the traditional file-by-file way.
VisualD and Mono-D also perform D compilation in single step, while
interoperating with C compilation in the traditional way.
Mar 19 2015
prev sibling parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 19 March 2015 at 07:49, Bruno Medeiros via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On 17/03/2015 23:45, Manu via Digitalmars-d-announce wrote:

 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.


 It makes no sense for DDT to use anything else than DUB.

 At a minimum, DDT needs a way to describe projects: the source files that
 are part of the project, and which other projects are dependencies of said
 project.
 Other aspects of a projects that are good to be able to describe are: which
 build configurations the project supports, which executables are produced
 (if any), etc..

 Now the reason DUB is used is that it's a bad paradigm for this description
 mechanism to be Eclipse/DDT specific. It's unequivocally much better to be
 Eclipse-independent, such that other tools (not just other IDEs, but even
 other command-line analysis tools) can understand D
 projects/bundles/packages just as well as DDT. It also saved me a lot of
 work. If I had to develop my own format to describe all these aspects, it
 would not be as good as DUB's, guaranteed! I reckon this is true for any
 other D IDE out there.


I use Mono-D and VisualD extensively, and in lieu of those, I fallback
to makefiles.
Those certainly did make their own equivalent build systems matching
the IDE's existing styles.
Those IDE's integrate D nicely with the C/C++ experiences.



 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.



 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?


I have no idea how Eclipse operates internally... and I shouldn't have
to. Isn't that the point of an IDE?
All I can say is that CDT works, and I don't know how. If DDT doesn't
automatically work with it out of the box, then the IDE experience is
kinda pointless (to me at least).
If I have to fiddle with a build system by hand, then that undermines
the whole point of the IDE as far as I'm concerned.

C/C++ and D are related, and they must interoperate. It's the top of
the D roadmap.
If I'm an IDE user, I think that's more-or-less an admission that I
don't understand build environments, and I don't want to.
So from that perspective, I think it would be valuable work to make
sure DDT and CDT understand eachother.



 The only problem so far is that DDT doesn't support mutiple build
 configurations, but that's a DDT limitation, not a DUB one.

 You can also disable the DUB builder in DDT, as albatroz mentioned, however
 that isn't ideal since you won't get the compiler build errors reported back
 to Eclipse (DDT only has parsing errors built-in, other errors come
 externally, from the compiler.).

 There should be a way to integrate DUB with your build environment.


There may very well be, but it would seem to be more work than not,
and added complexity and for the cost of additional work doesn't make
for a good sales pitch :)
As far as I can tell, dub is good for self-contained D apps, and
that's about it. Beyond that, there are much simpler solutions, and
that includes IDE support.
Mar 19 2015
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 20/03/2015 05:04, Manu via Digitalmars-d-announce wrote:

 On 19 March 2015 at 07:49, Bruno Medeiros via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 On 17/03/2015 23:45, Manu via Digitalmars-d-announce wrote:

 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.


 It makes no sense for DDT to use anything else than DUB.

 At a minimum, DDT needs a way to describe projects: the source files that
 are part of the project, and which other projects are dependencies of said
 project.
 Other aspects of a projects that are good to be able to describe are: which
 build configurations the project supports, which executables are produced
 (if any), etc..

 Now the reason DUB is used is that it's a bad paradigm for this description
 mechanism to be Eclipse/DDT specific. It's unequivocally much better to be
 Eclipse-independent, such that other tools (not just other IDEs, but even
 other command-line analysis tools) can understand D
 projects/bundles/packages just as well as DDT. It also saved me a lot of
 work. If I had to develop my own format to describe all these aspects, it
 would not be as good as DUB's, guaranteed! I reckon this is true for any
 other D IDE out there.


 I use Mono-D and VisualD extensively, and in lieu of those, I fallback
 to makefiles.
 Those certainly did make their own equivalent build systems matching
 the IDE's existing styles.
 Those IDE's integrate D nicely with the C/C++ experiences.


We might have different notions of what "as good as DUB's" means then.
Let's look at these two use cases:

* Do those IDEs allow a project specifying a dependency on an D library, 
without having to download the library, or to configure the build 
settings for the library? And does doing so still make it possible to 
integrate with C/C++ projects?

* Can you have a cross-plaftorm workspace/solution, and when building 
the D part of it, the IDE parses the error messages of the D compiler 
and reports then to the UI in the editor?



 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.



 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?


 I have no idea how Eclipse operates internally... and I shouldn't have
 to. Isn't that the point of an IDE?
 All I can say is that CDT works, and I don't know how. If DDT doesn't
 automatically work with it out of the box, then the IDE experience is
 kinda pointless (to me at least).
 If I have to fiddle with a build system by hand, then that undermines
 the whole point of the IDE as far as I'm concerned.

 C/C++ and D are related, and they must interoperate. It's the top of
 the D roadmap.
 If I'm an IDE user, I think that's more-or-less an admission that I
 don't understand build environments, and I don't want to.
 So from that perspective, I think it would be valuable work to make
 sure DDT and CDT understand eachother.


Yes, it would be nice if DDT would automatically integrate with CDT, and 
handle this use case seamlessly (regardless of using DUB internally or not).

But this would be complex work, for little gain. Let me go into detail.

First of all, "CDT works, and I don't know how": yeah, but CDT only had 
to concern himself with C/C++, no cross-language stuff. Like you said, 
DDT and DUB also works well if you stick to the D ecosystem only. If you 
put a cross-language requirement on DDT, you're actually asking more of 
DDT than CDT had to worry (which means more work, more complexity).

CDT and VisualStudio are IDEs with big companies backing them, they both 
had multiple developers working on them, full-time, for many, many years 
now.

DDT only has had me working on it, on a volunteer basis (although some 
of the work I do there, and in Goclipse and RustDT, is related to some 
commercial work I do). Still, it's just me ATM, so there is an order of 
magnitude of difference of manpower available. You can't expect the same 
level of completeness. Only the most critical/important features can be 
worked on (or simple to implement ones).

Also, there is limited gain. Sure, C/C++ and D are related, but
A) Not everyone in D world is that concerned with that scenario, C/C++ 
integration.
B) More importantly, adding DDT integration with CDT, would only benefit 
users of DDT&CDT combined, which is a fraction of 'C++ & D' users. What 
about users (and you might be one) that at the end of day don't use 
DDT/CDT because you can't debug properly on Windows, and go to VisualD?
What about CDT users that use unmanaged builds? (unmanaged builds is a 
CDT project option that has the user manually write/manage the build 
system files for that CDT project). Unmanaged builds are likely to be 
structured/specified in a way that would prevent seamless DDT 
integration. Rather, a DDT project using a CDT unmanaged build project, 
would have to be unmanaged as well, to a degree at least (that is, the 
user would have to fiddle with build systems configuration files). That 
further narrows down the population who would benefit from DDT+CDT 
integration.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 23 2015
prev sibling next sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
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)


Note that there is a tool recently released, Eclipse Optimizer, that can 
help optimize Eclipse startup time:

"Also, to improve Eclipse performance and startup time, it is 
recommended you tweak the JVM parameters. There is a tool called Eclipse 
Optimizer that can do that automatically, it is recommended you use it. 
Read more about it http://www.infoq.com/news/2015/03/eclipse-optimizer . 
(Installing/enabling the JRebel optimization is not necessary as that 
only applies to Java developers)"

I've added the above info to the User Guide.


Also, because Google Code is shutting down, I've moved the DDT project 
homepage to: http://ddt-ide.github.io/

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Mar 27 2015
prev sibling parent "anynous" <a b.xy> writes:
Is there an easy trick to run/debug unittests?

I found the dialog to add additional options for dub, but it
always executes
"dub build"

Copying the failing unittest into main() works, but I'd prefer
another solution :)

My current workaround is to run "dub --test" from the Linux
terminal. Dub compiles the tests and runs them (the second is
unnecessary but does not matter because tests are fast enough).

After that I can click debug in Eclipse and use the nice debug
support.
Mar 30 2015