On 2012-11-29 14:55, Andrei Alexandrescu wrote:

> Why not use D for that full-blown language? I know you insist on using
> Ruby, and I fail to grasp why we'd have D users learn Ruby in addition
> to D, when D is presumably already installed (since this is all about
> building D programs!) and D is as convenient for build scripting as Ruby.

I still think it's possible to have a smaller, less verbose and more simplistic build scripts written in Ruby. BUT I would choose a proper build tool with build scripts written in D any day over having to use shell scripts or your special kind of comments.

-- 
/Jacob Carlborg

That's my point. :-) This is basically about making the concept of a "build system for D" useless, due to D code being inherently capable of building itself.


On Thu, Nov 29, 2012 at 5:55 PM, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:

> On 11/29/12 2:36 AM, Jacob Carlborg wrote:
>
>> On 2012-11-28 22:24, 1100110 wrote:
>>
>>  Of course. I just can't remember the last time I needed something more
>>> complex than a shell script. It would be *really* nice if the syntax were nice and simple. Makefiles kick my @$$. Implicit rules, and all that.
>>>
>>
>> I'm just trying to stop you guys from investing in a new build system that cannot be used for the whole community.
>>
>> In most cases I also just need a shell script containing some compile/link flags. But what I don't like is that I need to duplicate the shell script, one version for Posix and one version for Windows. That's why I'm advocating for using build scripts written in a full blow language that already exists and works cross platform.
>>
>
> Why not use D for that full-blown language? I know you insist on using Ruby, and I fail to grasp why we'd have D users learn Ruby in addition to D, when D is presumably already installed (since this is all about building D programs!) and D is as convenient for build scripting as Ruby.
>
> Andrei
>



-- 
Bye,
Gor Gyolchanyan.

On 11/29/12 9:04 AM, Jacob Carlborg wrote:
> On 2012-11-29 14:55, Andrei Alexandrescu wrote:
>
>> Why not use D for that full-blown language? I know you insist on using
>> Ruby, and I fail to grasp why we'd have D users learn Ruby in addition
>> to D, when D is presumably already installed (since this is all about
>> building D programs!) and D is as convenient for build scripting as Ruby.
>
> I still think it's possible to have a smaller, less verbose and more
> simplistic build scripts written in Ruby.

Since you think (as opposed to believe), then there are reasons. What are those reasons, and what steps can we take to obviate them from the D side?

> BUT I would choose a proper
> build tool with build scripts written in D any day over having to use
> shell scripts or your special kind of comments.

Then why not work on it? A tool using D is much more likely to be accepted by the community than one using Ruby, and the latter will probably never be part of the official distro. I plan to change your Ruby installer creation scripts into shell scripts as soon as I'll have a minute.


Andrei

On 11/29/12 9:04 AM, Gor Gyolchanyan wrote:
> That's my point. :-) This is basically about making the concept of a
> "build system for D" useless, due to D code being inherently capable of
> building itself.

Getting the joke but not the point (if present).

Andrei

On 2012-11-29 15:04, Gor Gyolchanyan wrote:
> That's my point. :-) This is basically about making the concept of a
> "build system for D" useless, due to D code being inherently capable of
> building itself.

You will always need to be able to specify various link/compile flags.

-- 
/Jacob Carlborg

Sure, but that will be part of the code, so there will still be no build system, because the compiler will be able read the build info from the source.


On Thu, Nov 29, 2012 at 7:20 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2012-11-29 15:04, Gor Gyolchanyan wrote:
>
>> That's my point. :-) This is basically about making the concept of a "build system for D" useless, due to D code being inherently capable of building itself.
>>
>
> You will always need to be able to specify various link/compile flags.
>
> --
> /Jacob Carlborg
>



-- 
Bye,
Gor Gyolchanyan.

On Thursday, 29 November 2012 at 14:04:32 UTC, Jacob Carlborg wrote:
> I still think it's possible to have a smaller, less verbose and more simplistic build scripts written in Ruby. BUT I would choose a proper build tool with build scripts written in D any day over having to use shell scripts or your special kind of comments.

The very last thing I would want to do is to futz around installing Ruby and learning Ruby for the sole purpose of building a D application. Think about how massive a time sink that is for anyone who has no other reason to invest their valuable time into Ruby. I got sucked into this trap with Make, which wasted many hours of what should have been productive time, and I saw the exact same issues repeat when I investigated scons as a potential alternative. I just fail to see why this kind of complexity is necessary at all. If we can fix the problem at the source, then we should do it, rather than pile more mess on top of the existing pile of mess.

I do however think you have a good point wrt the use of "comments" for doing this stuff. Please do not use comments for this, make it a part of the language for real, like CTFE or something.

For example I find that implementing the ddoc system as "comments" was a mistake, because when you do it in that way, you think of those constructs as being comments like any other, and that limits the thinking concerning what can (or could have been) done with them. Ddoc could and should be much more than it is, even if it was started off in a limited way, it at least could have the potential to expand in a more useful way.

--rt

On 2012-11-29 15:28, Andrei Alexandrescu wrote:

> Since you think (as opposed to believe), then there are reasons. What
> are those reasons, and what steps can we take to obviate them from the D
> side?

Some features Ruby has that makes it less verbose to use:

* No semicolons
* Calling a method without parentheses
* Code can be executed basically every where. Global scope, module scope , class scope, method scope and function scope
* Blocks
* Easy to integrate into an application
* Relaxed syntax for associative array literals
* Dynamic typing can probably help as well

Actually, I'm a bit concerned about how I would do the actual integration if the build script was written in D. In Ruby it's easy, just do something like (written in D using libruby) :

# Build script in Ruby

target :foo do
end

// Handling the build script in D

string content = read(buildScript);
BuildScriptContext context = new BuildScriptContext;
context.instance_eval(content);

// access what's needed from "context"
string target = context.target;

writeln(target); // prints "foo"

> Then why not work on it? A tool using D is much more likely to be
> accepted by the community than one using Ruby, and the latter will
> probably never be part of the official distro.

That's not fair. I'm doing the best I can. I'm working on several D relate projects (including a build tool) and I don't have much time to work at D at all. I would really like to be able to work on these projects full time. But I don't know how to make money on that.

> I plan to change your
> Ruby installer creation scripts into shell scripts as soon as I'll have
> a minute.

How is that any better? Yeah I do know that you prefer shell scripts over Ruby. But you're arguing that I should use D instead of Ruby and then you're going to use shell script.

-- 
/Jacob Carlborg

On 2012-11-29 19:53, Rob T wrote:

> The very last thing I would want to do is to futz around installing Ruby
> and learning Ruby for the sole purpose of building a D application.

Ruby would not be a runtime dependency. It's embedded in the tool just like any other library. BTW, I never heard anyone complain about the DSSS build scripts. Which is completely custom, something like a combination of ini files and statements. Ruby is at least a real language. An example from DSSS:

version (build) {
    pragma(link, "example");
}

If I recall correctly, you need to use that exact syntax. If you move the first brace to a new line it won't work. That's the problem one get when using custom "languages" for these kind of things.

> Think about how massive a time sink that is for anyone who has no other
> reason to invest their valuable time into Ruby. I got sucked into this
> trap with Make, which wasted many hours of what should have been
> productive time, and I saw the exact same issues repeat when I
> investigated scons as a potential alternative. I just fail to see why
> this kind of complexity is necessary at all. If we can fix the problem
> at the source, then we should do it, rather than pile more mess on top
> of the existing pile of mess.

What's the difference compared to any other build tool. Where you have to learn some kind of special syntax. This is a special syntax as well, just happens to be a real language as well.

> I do however think you have a good point wrt the use of "comments" for
> doing this stuff. Please do not use comments for this, make it a part of
> the language for real, like CTFE or something.

I don't think that will work. How will the compiler handling imports paths? I need to have all imports path before starting to compile. Otherwise it needs to rescan the source files several times.

-- 
/Jacob Carlborg

On 2012-11-29 16:27, Gor Gyolchanyan wrote:
> Sure, but that will be part of the code, so there will still be no build
> system, because the compiler will be able read the build info from the
> source.

For the 10th time, how will it handle import paths?

-- 
/Jacob Carlborg