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.

On Friday, 20 March 2015 at 15:52:18 UTC, Dicebot wrote:
> It is _supposed_ to be the same, but not necessarily is. Bugs in CMake generators are not impossible.

Of course not, but I prefer a build system that works 99.99% of the time regardless of where it is used over a build system that can only be used on one machine or software stack.

> And I don't understand why it is not acceptable.

 * Because it is not guaranteed to be there. For instance, I don't have dub on my system
 * Because anybody not using dub should not be required to use dub. This is dlang, not dublang
 * Because it is at odds with C/C++ integration, which is an H1 priority
 * Because I just want to tell Eclipse about the project, there is no need to involve dub
 * Because the user said so

> dub is de-factor part of standard compiler toolchain for D.

No it isn't. Neither is rdmd. Nor is make part of the standard compiler toolchain for C. When CDT uses make it does so *because it was told to*. Same with ninja. VisualStudio project generation doesn't use makefiles, because it is generating a VisualStudio project.

And the fact that a whole bunch of abandoned single-module D libraries use dub is irrelevant when people like me, Manu, etc are working on larger, more complicated projects and say (repeatedly!!) that dub doesn't meet our needs.

> It is developed as D-Programming-Language organization project and planned for eventual distribution with compiler.

rdmd is already distributed with dmd. Is it now a required part of the build process for all projects?

VisualD is also developed under D-Programming-Language. Is it now required as well? Why isn't DDT using a .visualdproj?

> Saying that is unacceptable as dependency is similar to saying
> that Phobos is unacceptable as dependency.

I'm not saying Phobos is unacceptable, but there are those that do. However, phobos is a library, not a build tool. Apples, oranges, etc.

>> Include directories are not language specific, at least not in CMake.
>
> Sounds like design mistake to me. There is nothing similar between include directories in C and import paths in D.

It's a list of directories. Sure, the compilers might do different things with the directories, but I've never encountered any harm from there just being a single list of directories to look for includes/imports in.

> Even within D -J paths and -I paths need to be treated differently.

My fork handles -J paths separately from -I paths:

    include_directories(foo) # -Ifoo
    include_directories(TEXT bar) # -Jbar

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

    include_directories(SYSTEM baz) # -isystem baz

However, D doesn't have a -isystem, so SYSTEM is effectively ignored when producing the flags for a D compiler.

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

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

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

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

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

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.

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

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