On Sat, 13 May 2006 10:57:33 +1000, Ameer Armaly <ameer_armaly@hotmail.com> wrote:

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

So? If the tool is not worth using then don't use it. I'm not going to lose any sleep over it. The purpose of Build is to automate the 'building' process and if text processing can help somebody with that, it offers it.

I could have made a separate Text Processing Utility (which I might just do anyhow), but for now, my 'macro' library is being used by Build rather than having a separate process. So such an attitude might not sit well with tool chain purists but I simply don't care for now. The source is freely available for anyone to fork the tool.

-- 
Derek Parnell
Melbourne, Australia

"Mike Parker" <aldacron71@yahoo.com> wrote in message news:e43e2l$svk$1@digitaldaemon.com...
> 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.
I agree with your philosophy on tool chains, which is exactly why I advocate the full-build functionality being in the compiler proper.  As to the macro processor and related components, I just don't see any logical grouping for them along with project building, thus they should be in their own plugin.

Ameer Armaly wrote:
> "Mike Parker" <aldacron71@yahoo.com> wrote in message news:e43e2l$svk$1@digitaldaemon.com...
> 
>>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.
> 
> I agree with your philosophy on tool chains, which is exactly why I advocate the full-build functionality being in the compiler proper.  As to the macro processor and related components, I just don't see any logical grouping for them along with project building, thus they should be in their own plugin. 
> 
> 

I also agree with that all-in-one package ideal.  Simple experience has shown me that I do NOT enjoy hunting down multiple downloads, learning multiple interfaces, and dealing with a number of things that are totally unnecessary in about 99% of cases.

That said, I feel the argument against merging build and dmd is a good one.  Let Derek and Walter work in their most efficient ways.

My suggestion would be to bundle executables, not source.  Just stick a sufficiently recent version of build in with every release of dmd. Document its functionality along side dmd's, at least in a basic "heads up" sorta way.  This would save a very unnecessary step for every new D user on the path to having an intuitive setup for coding in D.

My typical routine for setting up D on a new computer looks like this:

Download/install dm linker
Download/install dmd compiler
Download build, toss build.exe into /dmd/bin
Set up environment paths as needed
(move onto other more specialized stuff here, like multimedia)


We could at least get rid of one step there.

Derek Parnell wrote:

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

But then I could just as well use "alias", in this particular case ?

The only reason that it is done manually in the first place - and not
automated, is that Walter declared he preferred the copy and paste...

--anders

Derek Parnell wrote:
> 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

Yet this kinda of thing seems worse than 'goto' and worse so that just not personally using it isn't enough. It begs for non-use advocacy to other people :/
You are, of course, free to do as you wish, but still..

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D