On Fri, Jul 12, 2013 at 1:42 PM, Tofu Ninja <[email protected]> wrote:
> So I had an idea recently, wouldn't it be cool to have the ability to call > an executable at compile time and capture its output. Something like the > string imports but instead of opening and reading a text file, it run an > executable, waits for it to finish, and grabs its output. > > It would get really cool if you could pass this executable some args and > then mix in its out put into your own code. It could be used similarly to > how CTFE are used but with out the overhead of trying to compile that > function and what not and with out the limitations on what it can do. > > I could imagine all sorts of things that would be possible with this that > is currently not. > > Not sure if this is something that could be implemented easily, but seems > like something that could be done and something that would be really cool. > I would definitely love that, and I don't see why this should be hard. It should be enabled by a compiler switch (dmd -enable_exec) for obvious safety reasons though (just as string import requires -J). This enables or simplifies a number of things: * ctfeWriteln becomes trivial (this feature has been asked a while ago) * CTFE in situations where current CTFE fails * do things that would temprarily require malloc * easily customize compilation process (user would be able to add logging / profile info without touching the dmd compiler) * accessing environment variables during compilation seems to me all that is needed is optionally redirecting stdin/stdout of a forked process inside dmd compilation, with the exec C function family.
