3122 – [patch] Adding support for fast and reliable build tools to the frontend

D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 3122 - [patch] Adding support for fast and reliable build tools to the frontend
Summary: [patch] Adding support for fast and reliable build tools to the frontend
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D1 (retired)
Hardware: All All
: P3 enhancement
Assignee: No Owner
URL:
Keywords: patch
Depends on:
Blocks:
Reported: 2009年07月01日 10:28 UTC by Tomasz Stachowiak
Modified: 2014年04月18日 09:12 UTC (History)
3 users (show)

See Also:


Attachments
DMD frontend patch (4.74 KB, patch)
2009年07月01日 10:28 UTC, Tomasz Stachowiak
Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Tomasz Stachowiak 2009年07月01日 10:28:11 UTC
Created attachment 410 [details] 
DMD frontend patch
Creating a reliable and fast build tool for D is a tricky business currently. Bu[il]d gets away with partial parsing of D files and is reasonably fast, but may miss some imports and doesn't guarantee proper incremental builds. ReBuild parses the project's modules by using the DMD frontend on them, then figures out which files to pass to the compiler. This approach may provide proper full and partial builds, but is slow because of duplicating a lot of work.
Leonard Dahlmann and myself have been working on a build tool that achieves both of these merits through a reasonable compromise. It requires a special patch to the compiler so it emits dependencies between modules to a file during the semantic analysis. This way it can track module dependencies and build projects by usually only running the compiler once (twice in special cases).
Tracking module dependencies is critical, because when A imports B and its code is conditionally generated upon some declarations in B, they both have to be recompiled whenever B is changed.
The patch has already been included in LDC 0.9.1 and works great with the first tool that can exploit the extra info the compiler provides thanks to it - xfBuild ( http://wiki.team0xf.com/index.php?n=Tools.XfBuild ). Several people have been testing it for more than a month with DMD as well on Linux and Windows, using a custom-patched version of DMD. It's proving to be consistently faster and more reliable than other build tools.
Summary of the diff:
The mars.c file is modified as to accept an additional switch "-deps=filename". This is to specify the file to which module dependencies are written in the following format ( the real work is done in import.c ):
----
ImportDeclaration
	::= BasicImportDeclaration [ " : " ImportBindList ] [ " -> " ModuleAliasIdentifier ] "\n"
BasicImportDeclaration
	::= ModuleFullyQualifiedName " (" FilePath ") : " Protection " [ " static" ] : " ModuleFullyQualifiedName " (" FilePath ")"
FilePath
	- any string with '(', ')' and '\' escaped with the '\' character
The ImportBindList, ModuleAliasIdentifier, ModuleFullyQualifiedName non-terminals are borrowed from http://digitalmars.com/d/1.0/module.html#ImportDeclaration with the exception of not allowing whitespace between substitution symbols
----
For example:
mod.ModA (mod\\ModA.d) : public : object (c:\\prog\\dmd\\bin\\..\\import\\object.di)
mod.ModCommon (mod\\ModCommon.d) : public : object (c:\\prog\\dmd\\bin\\..\\import\\object.di)
mod.ModA (mod\\ModA.d) : public : mod.ModCommon (mod\\ModCommon.d)
aliasedSelectiveImport (aliasedSelectiveImport.d) : public : tango.text.convert.Integer (c:\\prog\\dmd\\bin\\..\\import\\tango\\text\\convert\\Integer.d) : parse,toString32 -> Integer
----
The patch I've attached is Public Domain. It can be applied to DMD's source by running:
> patch -p0 -ui dmdDiff.patch
in the dmd/src directory, assuming DMD sources are in dmd/src/dmd. It's created against DMD 1.045. It might be necessary to run 'dos2unix' on the files to be patched (import.c, mars.c, mars.h) if doing it on a *nix.
Comment 1 anonymous4 2009年07月02日 02:03:54 UTC
Why not follow gcc approach and write deps in make format?
Comment 2 Tomasz Stachowiak 2009年07月02日 02:58:29 UTC
Uh, because no one had suggested it before... But well, looking at make dependency files, the format I've proposed carries more information which could be used not only for build tools, but also e.g. rendering import diagrams, finding import cycles or determining namespace pollution levels. It should also be easier to extend in the future, e.g. with info about where template instantiations end up, object-wise.
Comment 3 anonymous4 2009年07月02日 03:54:56 UTC
With make formatted deps you can use make tool with which you don't want to compete, do you? Other things you talk about are more of debugging or manual optimization.
Comment 4 Tomasz Stachowiak 2009年07月02日 07:51:49 UTC
It would be pretty easy to write a script to convert this output to a make-compatible format pretty much by removing the extra info. But you can't easily go the other way around and extract the more detailed info from a make-compatible format. Thus I'll stick to claiming that the patch does a better job than emitting make dependencies would :)
Comment 5 Walter Bright 2009年07月09日 02:52:41 UTC
Fixed dmd 1.046 and 2.031
Comment 6 david 2009年07月26日 20:39:36 UTC
Seems, the part of import::semantic not get folded in dmd 1.046.
Comment 7 Walter Bright 2009年09月03日 13:29:01 UTC
Fixed dmd 1.047


AltStyle によって変換されたページ (->オリジナル) /