DIP81: Writing files at compile time

via Digitalmars-d digitalmars-d at puremagic.com
Thu Aug 13 03:06:30 PDT 2015


On Thursday, 13 August 2015 at 09:52:02 UTC, JDemler wrote:
> This solves the concurrency problem. But what about non 
> concurrent compiler runs? A block there would never be 
> resolved. I do not know enough about compilers to judge this 
> problem. Can a sane way of compiling the files be found easily? 
> Can the compiler switch to compile something else when it is 
> blocked on an import?

You need a highly concurrent compiler. If you import in one 
definition and export in the next definition, then the first one 
would block and be queued, and the compiler would move on to the 
next definition.

In the actor-model (co-routines/fibers) each definition will 
spawn a new actor.

> And I do not understand why you differentiate between generated 
> source files and generated non source files (.xml, .ini). As 
> both types can be imported (or read at compile time) I do not 
> think we should treat them differently. Also we would need a 
> way to tell the one from the other (file extension? different 
> parameter in the export syntax?).
> In my understanding storage area 2 and 3 should be merged.

Area 2 is pre-populated with area 1, so they are the same.

You need to be able to tell the compiler what files should be 
included in the output bundle.

Actually, I think the file-model is too simple. I think you need 
a more advanced key-value database so that you can update 
different fields in the same ".ini file" from different source 
files.



More information about the Digitalmars-d mailing list