View mode: basic / threaded / horizontal-split · Log in · Help
November 29, 2012
Re: Errors compiling DSSS
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
November 29, 2012
Re: Errors compiling DSSS
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.
November 29, 2012
Re: Errors compiling DSSS
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
November 29, 2012
Re: Errors compiling DSSS
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
November 29, 2012
Re: Errors compiling DSSS
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
November 29, 2012
Re: Errors compiling DSSS
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.
November 29, 2012
Re: Errors compiling DSSS
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
November 29, 2012
Re: Errors compiling DSSS
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
November 29, 2012
Re: Errors compiling DSSS
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
November 29, 2012
Re: Errors compiling DSSS
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
3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home