View mode: basic / threaded / horizontal-split · Log in · Help
December 28, 2006
Re: Let the D compiler print the dependencies.
Derek Parnell wrote:
> On Wed, 27 Dec 2006 15:32:04 +0100, Frank Benoit (keinfarbton) wrote:
> 
>> While thinking about build tools and IDE integration, why not let the D
>> compiler have a switch to print the dependencies?
> 
> While this is a good idea, you do realize that the Bud tool can already do
> this? There is a switch to get it to create a file that contains a list of
> all the files is depends on.
> 

I think the idea is to get bud out of the "Lets see what this depends 
on" part of things. DMD has to do this by definition, why not let bud 
leverage this?
December 28, 2006
Re: Let the D compiler print the dependencies.
BCS wrote:
> Derek Parnell wrote:
>> On Wed, 27 Dec 2006 15:32:04 +0100, Frank Benoit (keinfarbton) wrote:
>>
>>> While thinking about build tools and IDE integration, why not let the D
>>> compiler have a switch to print the dependencies?
>>
>> While this is a good idea, you do realize that the Bud tool can 
>> already do
>> this? There is a switch to get it to create a file that contains a 
>> list of
>> all the files is depends on.
>>
> 
> I think the idea is to get bud out of the "Lets see what this depends 
> on" part of things. DMD has to do this by definition, why not let bud 
> leverage this?

Because Derek already worked his ass off to get bud to do that!!
December 28, 2006
Re: Let the D compiler print the dependencies.
Oh, that was new to me. The -uses and the -modules switches are not
listed in the option list. This is very nice and enables me to write a
kind of build tool I like without writing a parser and reimplementing
this logic.

Is there a possibility to get the list but without calling the compiler
or doing any further action? The -test option also disables the
-uses/-modules actions.
An ugly workaround I found is to supply a -dummy option, so dmd
immediately stops with complaining about the unrecognized option.
December 28, 2006
Re: Let the D compiler print the dependencies and pragma(lib,...).
To make any build tool completely independent from parsing the source
files, please print out the pragma( lib ) also.

I think, that this again shall be in the compiler, because this is also
dependent in evaluation of version and debug conditions. Implementing
this redundant into the build tools does not make sense.

To make the command line switches more easy, we can do all with one
switch and use the same format on stdout or the file.

-bldinfo
-bldinfo=filename
Prints the dependencies and the needed libs to stdout or [filename].
Output can look like this:
module imp: my.module => my.other.module
module imp: my.module => std.string
module imp: my.module => std.file
module lnk: my.module => mynativelib.dll
module lnk: my.module => mynativelib2.dll

What do you think? Is there something else missing?
December 28, 2006
Re: Let the D compiler print the dependencies and pragma(lib,...).
Frank Benoit (keinfarbton) wrote:
> To make any build tool completely independent from parsing the source
> files, please print out the pragma( lib ) also.
> 
> I think, that this again shall be in the compiler, because this is also
> dependent in evaluation of version and debug conditions. Implementing
> this redundant into the build tools does not make sense.

With all due respect to the work Derek has done here, a better 
(especially long-term, and theoretically) solution would be to have the 
compiler itself be the pivot of file dependency logic.

One of THE major principles of software development is the notion of 
_not_ duplicating data or information. Therefore we are simply obliged 
to let the compiler decide who, which, and when is dependent of whom.
December 28, 2006
Re: Let the D compiler print the dependencies and pragma(lib,...).
Georg Wrede wrote:
> Frank Benoit (keinfarbton) wrote:
>> To make any build tool completely independent from parsing the source
>> files, please print out the pragma( lib ) also.
>>
>> I think, that this again shall be in the compiler, because this is also
>> dependent in evaluation of version and debug conditions. Implementing
>> this redundant into the build tools does not make sense.
> 
> With all due respect to the work Derek has done here, a better 
> (especially long-term, and theoretically) solution would be to have the 
> compiler itself be the pivot of file dependency logic.
> 
> One of THE major principles of software development is the notion of 
> _not_ duplicating data or information. Therefore we are simply obliged 
> to let the compiler decide who, which, and when is dependent of whom.

Tell that to Walter... ;o

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home