www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3122] New: [patch] Adding support for fast and reliable build tools to the frontend

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3122

           Summary: [patch] Adding support for fast and reliable build
                    tools to the frontend
           Product: D
           Version: 1.045
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: patch
          Severity: enhancement
          Priority: P3
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: h3r3tic mat.uni.torun.pl


Created an attachment (id=410)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=410)
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 01 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3122






PDT ---
Why not follow gcc approach and write deps in make format?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 02 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3122






02:58:29 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 02 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3122






PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 02 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3122






07:51:49 PDT ---
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 :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 02 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3122


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |FIXED





02:52:41 PDT ---
Fixed dmd 1.046 and 2.031

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 09 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3122


david <davidl 126.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |davidl 126.com
         Resolution|FIXED                       |





Seems, the part of import::semantic not get folded in dmd 1.046.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 26 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3122


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED





13:29:01 PDT ---
Fixed dmd 1.047

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 03 2009