<br><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 4:51 PM, H. S. Teoh <span dir="ltr"><<a href="mailto:hsteoh@quickfur.ath.cx" target="_blank">hsteoh@quickfur.ath.cx</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sat, Jul 13, 2013 at 12:51:03AM +0200, Tofu Ninja wrote:<br>
> On Friday, 12 July 2013 at 22:36:22 UTC, Peter Alexander wrote:<br>
> >On Friday, 12 July 2013 at 20:42:50 UTC, Tofu Ninja wrote:<br>
> >>So I had an idea recently, wouldn't it be cool to have the<br>
> >>ability to call an executable at compile time and capture its<br>
> >>output.<br>
> ><br>
> >How long until D compilers are able to read mail? :-)<br>
<br>
</div>Zawinski's law of software envelopment:<br>
<br>
        Every program attempts to expand until it can read mail. Those<br>
        programs which cannot so expand are replaced by ones which can.</blockquote><div><br></div><div>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) </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">:-)<br>
<br>
<br>
> >There's many obvious applications of this proposed feature, but I<br>
> >say such things should be delegated to the build process. Just run<br>
> >those executables using a makefile, or whatever build system you<br>
> >use.<br>
> ><br>
> >If you need compile time inputs from your D code then just run a<br>
> >separate build to extract them. Yes it's more work and less<br>
> >convenient, but I think we need to be careful with how much is<br>
> >added to the D compilers. We don't want to turn them into<br>
> >operating systems.<br>
><br>
> I think this is in line with what you want though, it allows the<br>
> things that really should be separate to be separate in another<br>
> executable, the only thing that it is really bring into the language<br>
> is that you wont have to rely on a makefile as much, which in my<br>
> opinion is a good thing.<br>
<br>
</div>Makefiles are really a poor example of build systems. A proper build<br>
system can do such things in a much better, consistent way.<br>
<br>
Makefiles, for example, can't correctly recompile your program if you<br>
change compiler flags. And complex interdependencies, like you said,<br>
require painful manual maintenance, otherwise they tend to screw up and<br>
produce inconsistent results.<br>
<br>
For an example of a modern build system, see <a href="http://gittup.org/tup/" target="_blank">http://gittup.org/tup/</a>.<br><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Using a build system would likely be non-portable (see current mess even in dmd source code, which requires <a href="http://posix.ma">posix.ma</a> / win32.mak / win64.mak which is not DRY and hard to maintain), and suffer from the points I mentioned in my previous post.</div>
<div><br></div><div><div>We don't need yet another build system if we have "exec" available at CT.</div></div><div> </div><div>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?</div>
<div><br></div></div><br>