digitalmars.D - Let the D compiler print the dependencies.
- Frank Benoit (keinfarbton) (17/17) Dec 27 2006 While thinking about build tools and IDE integration, why not let the D
- Georg Wrede (4/24) Dec 27 2006 Absolutely!
- Johan Granberg (5/27) Dec 27 2006 Itsounds like a good idea but I think that printing depend: infront of t...
- Frank Benoit (keinfarbton) (9/12) Dec 27 2006 My idea behind that was, that printing the dependencies is independent
- Frank Benoit (keinfarbton) (6/8) Dec 27 2006 If the file is actually missing, the compiler perhaps does not know the
- Johan Granberg (5/15) Dec 27 2006 Ok I see the problem with missing files.
- Johan Granberg (6/13) Dec 27 2006 The previous message got sent beore it was finnished. here it goes.
- Frank Benoit (keinfarbton) (2/2) Dec 27 2006 This should do it:
- Frank Benoit (keinfarbton) (2/2) Dec 27 2006 Ah sorry, certainly you need the filename here :)
- Derek Parnell (6/8) Dec 27 2006 While this is a good idea, you do realize that the Bud tool can already ...
- BCS (4/13) Dec 27 2006 I think the idea is to get bud out of the "Lets see what this depends
- Hasan Aljudy (2/18) Dec 27 2006 Because Derek already worked his ass off to get bud to do that!!
- Frank Benoit (keinfarbton) (9/9) Dec 28 2006 Oh, that was new to me. The -uses and the -modules switches are not
- Frank Benoit (keinfarbton) (17/17) Dec 28 2006 To make any build tool completely independent from parsing the source
- Georg Wrede (7/13) Dec 28 2006 With all due respect to the work Derek has done here, a better
- Bruno Medeiros (5/20) Dec 28 2006 Tell that to Walter... ;o
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
Georg Wrede <georg.wrede nospam.org> 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
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? FrankItsounds 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
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
(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
Frank Benoit (keinfarbton) 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`(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
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
This should do it: dmd -deps file.d | grep "depends : " | cut -c 10- | xargs grep text
Dec 27 2006
Ah sorry, certainly you need the filename here :) forget about my previous posting
Dec 27 2006
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
Derek Parnell wrote:On Wed, 27 Dec 2006 15:32:04 +0100, Frank Benoit (keinfarbton) wrote: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?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.
Dec 27 2006
BCS wrote:Derek Parnell wrote:Because Derek already worked his ass off to get bud to do that!!On Wed, 27 Dec 2006 15:32:04 +0100, Frank Benoit (keinfarbton) wrote: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?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.
Dec 27 2006
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
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
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
Georg Wrede wrote:Frank Benoit (keinfarbton) wrote:Tell that to Walter... ;o -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#DTo 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