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

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

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

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

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

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

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.

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

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

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.