build in the compiler was Re: version and debug statements

[Derek Parnell]

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

>
> "Derek Parnell" <derek at psych.ward> wrote in message
> news:op.s9c0g6vc6b8z09 at ginger...
>> On Sat, 13 May 2006 06:25:13 +1000, Ameer Armaly
>> <ameer_armaly at 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