www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Let the D compiler print the dependencies.

reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
While thinking about build tools and IDE integration, why not let the D
compiler have a switch to print the dependencies?


depends: std.string

This has the advantage, that if there is a change in the rules how
version/debug/static-if are evaluated, the build tool does not need to
know about them. The build tool can use different compilers and compiler
versions and can ask the compiler for the list of dependencies for a
given module.

-deps
Prints the dependencies, each in one line, starting with "depends: ".
-deps=filename
Prints the dependencies into the given file, each in one line without
additional text.

Does this make sense?
What do you think?

Frank
Dec 27 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
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?
 

 depends: std.string
 
 This has the advantage, that if there is a change in the rules how
 version/debug/static-if are evaluated, the build tool does not need to
 know about them. The build tool can use different compilers and compiler
 versions and can ask the compiler for the list of dependencies for a
 given module.
 
 -deps
 Prints the dependencies, each in one line, starting with "depends: ".
 -deps=filename
 Prints the dependencies into the given file, each in one line without
 additional text.
 
 Does this make sense?
 What do you think?
Absolutely! The compiler should be the only thing that needs to know the dependencies, and the other tools should ask it.
Dec 27 2006
prev sibling next sibling parent reply Johan Granberg <lijat.meREM OVE.gmail.com> writes:
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?
 

 depends: std.string
 
 This has the advantage, that if there is a change in the rules how
 version/debug/static-if are evaluated, the build tool does not need to
 know about them. The build tool can use different compilers and compiler
 versions and can ask the compiler for the list of dependencies for a
 given module.
 
 -deps
 Prints the dependencies, each in one line, starting with "depends: ".
 -deps=filename
 Prints the dependencies into the given file, each in one line without
 additional text.
 
 Does this make sense?
 What do you think?
 
 Frank
Itsounds like a good idea but I think that printing depend: infront of th e dependencies could complicate the use of the command. for example if you want to pipe it to another command. (I also think it should print filnames and not moduenames, or have two switches)
Dec 27 2006
next sibling parent "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
 It sounds like a good idea but I think that printing depend: in front of the
 dependencies could complicate the use of the command. for example if you
 want to pipe it to another command. 
My idea behind that was, that printing the dependencies is independent from doing compilation or other tasks (ddoc). Prefixing the message, makes this possible. The build tool can cache the dependencies from a previous run. First it calls the compiler with all files from the last run. If it turns out, that dependencies changed since the last run, it can rerun the compiler with the new complete set of files. With this, it is possible to compile most of the time without loading all source two times. All other messages can be filtered and printed to stdout/stderr.
Dec 27 2006
prev sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
 (I also think it should print filnames
 and not moduenames, or have two switches)
If the file is actually missing, the compiler perhaps does not know the filename. It can be in a missing search path and it can be a .d or .di file. So printing the module name will always work. The build tool can than search in in the project folders or can start a download of the missing sources, or something like that... then start a new compile run.
Dec 27 2006
parent reply Johan Granberg <lijat.meREM OVE.gmail.com> writes:
Frank Benoit (keinfarbton) wrote:

 (I also think it should print filnames
 and not moduenames, or have two switches)
If the file is actually missing, the compiler perhaps does not know the filename. It can be in a missing search path and it can be a .d or .di file. So printing the module name will always work. The build tool can than search in in the project folders or can start a download of the missing sources, or something like that... then start a new compile run.
Ok I see the problem with missing files. The reason I wanted it was to be able to write somthing like this. grep text `dmd -deps file.d`
Dec 27 2006
parent reply Johan Granberg <lijat.meREM OVE.gmail.com> writes:
Johan Granberg wrote:
 
 Ok I see the problem with missing files.
 
 The reason I wanted it was to be able to write somthing like this.
 

 grep text `dmd -deps file.d`
The previous message got sent beore it was finnished. here it goes. I wanted the above comand to search for the text in all modules that file.d depends on (including file.d but that could be a special case). Things like this can be usefull when searcing for function signatures when one does not know in which file they are defined.
Dec 27 2006
parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
This should do it:
dmd -deps file.d | grep "depends : " | cut -c 10- | xargs grep text
Dec 27 2006
parent "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Ah sorry, certainly you need the filename here :)
forget about my previous posting
Dec 27 2006
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
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. -- Derek Parnell
Dec 27 2006
next sibling parent reply BCS <BCS pathilink.com> writes:
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?
Dec 27 2006
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
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!!
Dec 27 2006
prev sibling parent "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
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.
Dec 28 2006
prev sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
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?
Dec 28 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
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.
Dec 28 2006
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Dec 28 2006