Compile time executable calling?

[H. S. Teoh]

On Wed, Jan 08, 2014 at 10:29:03PM +0000, Tofu Ninja wrote:
> On Wednesday, 8 January 2014 at 22:01:56 UTC, Brian Schott wrote:
> >Just make your makefile run the script, pipe its output to a file,
> >and do a string import of the generated file.
> 
> The kind of stuff I want to use it for would make that tactic
> tedious and error prone. I would use it like how ctfe is used now.
> 
> Having multiple points in the source(maybe hundreds) that would call
> out to a external program at compile time but pass out different
> args. Relying on a makefile to do something like this would require
> me to keep the makefile and the source code constantly in sync and
> would become a problem before long.

Huh? Your last sentence made no sense to me. Doesn't the makefile have
to be kept in sync anyway? In my experience, when makefile and source go
out of sync, that's when you start getting untraceable heisenbugs that
defy all analysis, and disappear after you do a `make clean; make`. The
most usual cause of this is the makefile picking up stray, stale object
files that should no longer exist 'cos they don't reflect the source
anymore.

<offtopic rant>
This is one of the many things I really hate about makefiles.  I'd
recommend *anything* over makefiles. Like SCons. Or tup. Even Ant, that
insists on the human-unreadable and human-unwriteable XML as an input
format.  A *shell script* could do better than make, by actually making
sure that everything is recompiled and up-to-date, without magic global
variables that alter behaviour in strange ways (*cough*VPATH*cough*), or
unreliable timestamp-dependence that breaks when you cross NFS
boundaries, or sometimes just breaks for no discernible reason
whatsoever. The fact that `make clean` exists at all, is a testament to
just how broken the whole thing is (and the saddest thing is that `make
clean` has come to be accepted as a part of life, when it shouldn't even
exist in the first place, had build systems been designed correctly to
begin with).
</offtopic rant>


T

-- 
In order to understand recursion you must first understand recursion.