version and debug statements

[Ameer Armaly]

"Bruno Medeiros" <brunodomedeirosATgmail at SPAM.com> wrote in message 
news:e4238i$20ln$1 at digitaldaemon.com...
> pagma wrote:
>> In article <e4069c$2da5$1 at digitaldaemon.com>, Ameer Armaly says...
>>>
>>> "Derek Parnell" <derek at psych.ward> wrote in message 
>>> news:op.s9d3gilp6b8z09 at ginger...
>>>> On Thu, 11 May 2006 19:32:07 +1000, Don Clugston <dac at 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