[Omake] Omake for the D programming language SCANNER

[Susanne Lietz]

Aleksey Nogin schrieb:
> 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
>
>   
Yes, I am aware of this feature !
> 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.
>
>   
As said to Dirk, actually we are using the D compiler frontend to build 
software. But in my opinion this is simply overkill.
In other words .
It is IMO redicoulous to "hire" an full educated compiler front-end guy  
to do such a simple task. Named : solving dependencies.
To be more concrete ;
Lets say I send you a  "code-analyser"  doing simple lexing ... 
examining  imports.. solving dependencies... aprox. 150-300 lines of 
C-ish  code, . 
do you see a chance   to port my C-ish (D) code to OMake-script ?  

> Jason even has a C parser written in OMake, so this is doable...
>
>   
Sorry, Aleksey I am new, (brand-new, to be more exact) to 
OCaml/Omake.... know about ML 'cause I met an AIRBUS Seniour developer 
last year... haven't heard much about OCaml  before ... as  mentioned in 
my first message. )

But well, a C parser requires a C preprocessor impl. and that's  indeed 
a bit more than what I am looking for. ......

Thanks for spending your time.    
> Aleksey
> _______________________________________________
> Omake mailing list
> Omake at metaprl.org
> https://lists.metaprl.org/mailman/listinfo/omake
>
>
>