[Omake] Omake for the D programming language SCANNER

[Aleksey Nogin]

On 20.02.2008 08:09, Susanne Lietz wrote:

> Hello Aleksey,  Thanks, you are very generous. ...
> thinking about the D semantics, (ignoring syntax sugar) I have to say
> that we can reduce the rules (regarding import depandencies)  to :
> 
> import a.b.c;   // where c is the file in directory a/b called c.d
> privat import a.b.c; is th  // has the same meaning
> public import a.x; // means : whenever we change the file x.d, every
> file who has a INDERECT relations to x.d should be re-compiled.
> static import  whatever.dsource.d // same story.
> I think we can ignore the syntactic sugar  like :
> import
> {
> WhatEverScope.d.;
> }
> But  , (comma) delimited import is also possible.
> import a.c, a.f, d.e;
> 
> Small and dirty conclusion :
> D packages, are in fact directories , public imports have an impact on
> recompile.
> -+---------
> adir.bdir.cdir.myfile.d   // means  adir/bdir/cdir/myfile.d ->
> directoryname is Package name.
> 
Susanne,

Do you know that OMake has support for creating lexers and parsers? Some
documentation (possibly slightly out-of-date) is available at
http://omake.metaprl.org/manual/omake-system.html#obj:Lexer

So, if you really needed to, you could define a grammar of the D's
"import" sequences (even the "import {WhatEverScope.d.;}" stuff) to get
the dependency scanner to be really robust.

To be honest, it would probably be easier to use an existing D paser
from the D compiler and teach it how to output the dependencies in a
form OMake would understand, but if that's not an option, then writing a
D parser in OMake might be a reasonable thing to do. If you could eat
least grab the grammar from the existing parser, then it would be a lot
easier.

Jason even has a C parser written in OMake, so this is doable...

Aleksey