digitalmars.D - Let the D compiler print the dependencies.
- "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> Dec 27 2006
- Georg Wrede <georg.wrede nospam.org> Dec 27 2006
- Johan Granberg <lijat.meREM OVE.gmail.com> Dec 27 2006
- "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> Dec 27 2006
- "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> Dec 27 2006
- Derek Parnell <derek psych.ward> Dec 27 2006
- BCS <BCS pathilink.com> Dec 27 2006
- Hasan Aljudy <hasan.aljudy gmail.com> Dec 27 2006
- "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> Dec 28 2006
- "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> Dec 28 2006
- Georg Wrede <georg.wrede nospam.org> Dec 28 2006
- Bruno Medeiros <brunodomedeiros+spam com.gmail> Dec 28 2006
While thinking about build tools and IDE integration, why not let the D compiler have a switch to print the dependencies? # dmd t.d -c -deps 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? # dmd t.d -c -deps 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? # dmd t.d -c -deps 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
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:(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. # bash code grep text `dmd -deps file.d`
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. # bash code 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: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
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
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: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