Compile time executable calling?

Timothee Cour thelastmammoth at gmail.com
Fri Jul 12 17:00:29 PDT 2013


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)



> :-)
>
>
> > >There's many obvious applications of this proposed feature, but I
> > >say such things should be delegated to the build process. Just run
> > >those executables using a makefile, or whatever build system you
> > >use.
> > >
> > >If you need compile time inputs from your D code then just run a
> > >separate build to extract them. Yes it's more work and less
> > >convenient, but I think we need to be careful with how much is
> > >added to the D compilers. We don't want to turn them into
> > >operating systems.
> >
> > I think this is in line with what you want though, it allows the
> > things that really should be separate to be separate in another
> > executable, the only thing that it is really bring into the language
> > is that you wont have to rely on a makefile as much, which in my
> > opinion is a good thing.
>
> Makefiles are really a poor example of build systems. A proper build
> system can do such things in a much better, consistent way.
>
> 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.

We don't need yet another build system if we have "exec" available at CT.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130712/cefd77cc/attachment-0001.html>


More information about the Digitalmars-d mailing list