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