Compile time executable calling?

[Timothee Cour]

On Fri, Jul 12, 2013 at 5:10 PM, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:

> On Fri, Jul 12, 2013 at 05:00:29PM -0700, Timothee Cour wrote:
> > On Fri, Jul 12, 2013 at 4:51 PM, H. S. Teoh <hsteoh at quickfur.ath.cx>
> wrote:
> >
> > > On Sat, Jul 13, 2013 at 12:51:03AM +0200, Tofu Ninja wrote:
> > > > On Friday, 12 July 2013 at 22:36:22 UTC, Peter Alexander wrote:
> > > > >On Friday, 12 July 2013 at 20:42:50 UTC, Tofu Ninja 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.
> > > > >
> > > > >How long until D compilers are able to read mail? :-)
> > >
> > > Zawinski's law of software envelopment:
> > >
> > >         Every program attempts to expand until it can read mail. Those
> > >         programs which cannot so expand are replaced by ones which can.
> >
> >
> > forget about reading mail, we currently don't even have hello world! (we
> > have pragma(msg) but no ctfewriteln, which pragma(msg) can't do)
>
> Why should the compiler turn into a hello world program?
>


For logging / debugging purposes, we often need to be able to print at
compile time some variables, but ctfeWriteln doesn't even work. And again,
pragma(msg) can't replace it.



> [...]
> > > Makefiles, for example, can't correctly recompile your program if you
> > > change compiler flags. And complex interdependencies, like you said,
> > > require painful manual maintenance, otherwise they tend to screw up and
> > > produce inconsistent results.
> > >
> > > For an example of a modern build system, see http://gittup.org/tup/.
> > >
> > >
> > Using a build system would likely be non-portable (see current mess
> > even in dmd source code, which requires posix.ma / win32.mak /
> > win64.mak which is not DRY and hard to maintain), and suffer from the
> > points I mentioned in my previous post.
>
> Again, makefiles are a poor example of build systems. There *are* build
> systems that allow you to write portable build scripts, such as SCons.
> They're not perfect, but makefiles are a far cry from what they can do.
>
>
> > We don't need yet another build system if we have "exec" available at
> > CT.
>
> That doesn't replace a proper build system.


I wrote a D based makefile-like tool in D (which uses direct acyclic graph
to find compilation order). It's much cleaner in D for obvious reasons.


> What if your external program itself is a D program that needs to be
> compiled first?


call exec("dmd mydeps.d"); (or exec("make -all") or the D based makefile)


> What if you need to run an external program like povray in order to
> generate
> images (say, animation frames) that are string-imported into your
> program?


I don't see how that's different:
void main(){
enum s=exec("program generating images");
import(s);
//use the string import
//or even simply: use s directly, depending on conditions
}



> Should DMD have the capability of running arbitrary programs
> that produce arbitrary output and be able to sort out which programs
> must run first and which output should be imported into the D program?
>

The order would be simply program order, as in the example above: "enum
s=exec(...)" is run during CTFE before import(s), as it comes first.


> So we're no longer talking about the D compiler, but about the D
> operating system. The real "DOS". :-P Which, mind you, would be a good
> thing IMO, but I think it's a bit of a stretch from where we are
> currently.
>

No, all it requires in terms of dmd modification is CTFE exec.
The user can use it to do complex stuff if he so wishes.

CTFE already runs very complex program (involving std.algorithm and
whatnot), so there's already a justification for running complex programs
during CTFE. Allowing that one simple function will enable many more
things.


> > Let's put it another way: if I or someone else made a pull request for
> > CTFE "exec", would it have a chance of being accepted?
>
> I'm not one to decide, you have to convince Walter.
>
> And I'm not saying this idea is good or bad, I'm just saying that you
> can already do such things without compiler support.


we can't even print variables during CTFE. Using a build system to do that
is way overkill.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130712/9c93185d/attachment.html>