On Fri, 12 May 2006 23:41:09 +1000, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:


> On the other hand, it happens that here that the "each do a particular job well" has something to be said: there is much overlap in the jobs of both utils (the compiler and build), such in fact that I think their jobs are not that different.

However, with the next release of Build the differences will be much more pronounced. I've completed the coding for v3.0 of Build and I'm just tidying up the docs this weekend. The main new feature, which btw makes it diverge from DMD, is a macro processor. At this stage its only a text replacement feature but in subsequent releases it will have a fully functional macro processor included (which is already designed and prototyped).

Just as an example, it can now transform things such as
  "for i = 1 to 100 do"
to
  "for(int i = 1; i <= 100; i++){"

-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:
> On Fri, 12 May 2006 23:41:09 +1000, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:
> 
> 
>> On the other hand, it happens that here that the "each do a particular job well" has something to be said: there is much overlap in the jobs of both utils (the compiler and build), such in fact that I think their jobs are not that different.
> 
> However, with the next release of Build the differences will be much more pronounced. I've completed the coding for v3.0 of Build and I'm just tidying up the docs this weekend. The main new feature, which btw makes it diverge from DMD, is a macro processor. At this stage its only a text replacement feature but in subsequent releases it will have a fully functional macro processor included (which is already designed and prototyped).
> 
> Just as an example, it can now transform things such as
>   "for i = 1 to 100 do"
> to
>   "for(int i = 1; i <= 100; i++){"
> 
> --Derek Parnell
> Melbourne, Australia

I thought this sort of thing was generally decided to be A Bad Thing™

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright

"Bruno Medeiros" <brunodomedeirosATgmail@SPAM.com> wrote in message news:e4238i$20ln$1@digitaldaemon.com...
> pagma wrote:
>> In article <e4069c$2da5$1@digitaldaemon.com>, Ameer Armaly says...
>>>
>>> "Derek Parnell" <derek@psych.ward> wrote in message news:op.s9d3gilp6b8z09@ginger...
>>>> On Thu, 11 May 2006 19:32:07 +1000, Don Clugston <dac@nospam.com.au> wrote:
>>>>
>>>>
>>>>> Since "static if" is now legal at module scope, it's now practically a superset of "version". So it shouldn't be very complicated to move some of the functionality across. (There's a problem with using 'static if' instead of 'version' : if there's an 'import' statement bracketed by a static if, potentially you have to compile the program to find out which files are included. Obviously 'build' can't cope with that).
>>>> And I don't want to make Build be a compiler too ;-) So I don't think it will ever try to execute static if statements.
>>>>
>>> Just a random thought, but what about moving at least some of the project functionality of build directly in to the compiler; have it compile all current directory imports and link them together.  If -c is supplied, then the compiler would compile them only as opposed to linking, facilitating flexible build processes.  An advantage of this sort of approach is that the compiler already needs to know all about imports and locations, so the logical extension of that idea would be to have the compiler act on them. This is just something I came up with randomly while reading this thread; I don't know whether or not it's been proposed before.
>>
>> AFAIK its been proposed before.  I think the opinion of many was that the
>> benefit of having many utils that each do a particular job well,
>> outweighs the
>> strengths of a single swiss-army-style application; hence the term
>> "toolchain".
>> This also happens to be the main philosophy behind Unix in general, and
>> (IMO) is
>> one of the main reasons why the parts that have always worked well
>> continue to
>> do so. :)
>>
>> Also, In the case of DMD and Build, each is maintained by a separate
>> person - we
>> get far better man/hr per LOC coverage this way than if Walter has to
>> manage
>> both feature sets. ;)
>>
>> - EricAnderton at yahoo
>
> On the other hand, it happens that here that the "each do a particular job
> well" has something to be said: there is much overlap in the jobs of both
> utils (the compiler and build), such in fact that I think their jobs are
> not that different.
> And as an example, the java compiler (javac) does this.
>
>
Plus, the same rationale for the code coverage analysis feature could be applied here: it requires an understanding of the language in order to process imports, something that the compiler already has.  Thus, if the compiler were to take that information and use it to build whole projects, IMO it would be a bit more efficient.
> -- 
> Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

"Derek Parnell" <derek@psych.ward> wrote in message news:op.s9cnlnwc6b8z09@ginger...
> On Fri, 12 May 2006 23:41:09 +1000, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:
>
>
>> On the other hand, it happens that here that the "each do a particular job well" has something to be said: there is much overlap in the jobs of both utils (the compiler and build), such in fact that I think their jobs are not that different.
>
> However, with the next release of Build the differences will be much more pronounced. I've completed the coding for v3.0 of Build and I'm just tidying up the docs this weekend. The main new feature, which btw makes it diverge from DMD, is a macro processor. At this stage its only a text replacement feature but in subsequent releases it will have a fully functional macro processor included (which is already designed and prototyped).
>
> Just as an example, it can now transform things such as
>   "for i = 1 to 100 do"
> to
>   "for(int i = 1; i <= 100; i++){"
>
Perhaps, but does this functionality really fall under the domain of a project management and automation program?
> -- 
> Derek Parnell
> Melbourne, Australia

Walter Bright wrote:

>>> DMD supports Windows and Linux; Unix is neither. For a compiler which targets the Unix operating system, it should set the Unix version.
>>
>> It does... I was just hoping to be able to use the same code for both ?
> 
> I know it seems like the right thing to do to use the same code for both operating systems. I'm going to argue that this is a case where copy/paste might be better.

I began copying/pasting, then. It's going to be three active versions:

* version (Windows) // for all
* version (linux)   // for DMD
* version (Unix)    // for GDC


version(Unix) should probably come before version(linux), since older
GDC versions came with a non-existent or incomplete std.c.linux.linux.

version (Windows)
{
    private import std.c.windows.windows;
}
else version (Unix)
{
    private import std.c.unix.unix;
}
else version (linux)
{
    private import std.c.linux.linux;
}
else static assert(0);


It will end up in a LOT of duplicated code, though. Previously it was
being shared with the Unix version by using alias and setting version:

else version (Unix)
{
    private import std.c.unix.unix;
    alias std.c.unix.unix unix;
}
else version (linux)
{
    version = Unix;
    private import std.c.linux.linux;
    alias std.c.linux.linux unix;
}

That way both DMD and GDC could share the "Unix" section of the code ?
(I'm not going to use "darwin" here, that'll be way too many versions)

--anders

On Sat, 13 May 2006 05:44:27 +1000, Kyle Furlong <kylefurlong@gmail.com> wrote:

> Derek Parnell wrote:


>> The main new feature, which btw makes it diverge from DMD, is a macro processor.

> I thought this sort of thing was generally decided to be A Bad Thing™


So don't use it. Like 'goto'.

-- 
Derek Parnell
Melbourne, Australia

On Sat, 13 May 2006 06:25:13 +1000, Ameer Armaly <ameer_armaly@hotmail.com> wrote:



>>
>> Just as an example, it can now transform things such as
>>   "for i = 1 to 100 do"
>> to
>>   "for(int i = 1; i <= 100; i++){"
>>
> Perhaps, but does this functionality really fall under the domain of a
> project management and automation program?

I neither know nor care. ;-)

-- 
Derek Parnell
Melbourne, Australia

On Sat, 13 May 2006 09:11:36 +1000, Anders F Björklund <afb@algonet.se> wrote:

> Walter Bright wrote:
>
>>>> DMD supports Windows and Linux; Unix is neither. For a compiler which targets the Unix operating system, it should set the Unix version.
>>>
>>> It does... I was just hoping to be able to use the same code for both ?
>>  I know it seems like the right thing to do to use the same code for both operating systems. I'm going to argue that this is a case where copy/paste might be better.
>
> I began copying/pasting, then. It's going to be three active versions:
>
> * version (Windows) // for all
> * version (linux)   // for DMD
> * version (Unix)    // for GDC

This is one of the reasons why Build will have text-processing functionality in it...to automate the copy/paste mechanism in such cases.

-- 
Derek Parnell
Melbourne, Australia

"Derek Parnell" <derek@psych.ward> wrote in message news:op.s9c0g6vc6b8z09@ginger...
> On Sat, 13 May 2006 06:25:13 +1000, Ameer Armaly <ameer_armaly@hotmail.com> wrote:
>
>
>
>>>
>>> Just as an example, it can now transform things such as
>>>   "for i = 1 to 100 do"
>>> to
>>>   "for(int i = 1; i <= 100; i++){"
>>>
>> Perhaps, but does this functionality really fall under the domain of a project management and automation program?
>
> I neither know nor care. ;-)
>
But that's exactly my point- a macro processor is independent of automatic building, so why stuff them together in the same package, especially since it almost invents a new layered language?  Furthermore, since building is really nothing mroe than taking advantage of already present information in the compilation phase, it would be redundant not to at least consider the idea of combining the two.  By not knowing and caring, you're essentially putting together a secondary layered compiler with various features but without any consideration as to whether or not they actually belong there.
> -- 
> Derek Parnell
> Melbourne, Australia

Ameer Armaly wrote:

> But that's exactly my point- a macro processor is independent of automatic building, so why stuff them together in the same package, especially since it almost invents a new layered language?  Furthermore, since building is really nothing mroe than taking advantage of already present information in the compilation phase, it would be redundant not to at least consider the idea of combining the two.  By not knowing and caring, you're essentially putting together a secondary layered compiler with various features but without any consideration as to whether or not they actually belong there.

Does it really matter? Having extra functionality in one tool is a convenience I find attractive. I hate having multiple tools in a tool chain. The more functionality Build gives me in one package, the better.