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

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

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.

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

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.

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

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.

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.

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

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