On Fri, 19 Dec 2008 21:30:28 -0500 Norman Ramsey wrote:
> It helps enormously to know that nmake is explicitly intended to
> capture platform-specific variables in a standard way. For people
> like me who use weird programming languages and lots of machine-generated
> code, however, we need to be able to know how to extend the mechanism.
probe(1) is the extension mechanism
the probe information for nmake for the C language compiler cc is listed by
probe -l C make cc
the part that does the real work is the probe script, e.g.,
$INSTALLROOT/lib/probe/C/make/probe
other languages would build on this
probe -l my-language make my-language-processor
would have a probe script in
$INSTALLROOT/lib/probe/my-language/make/probe
the probe script and the "my-language" make rules share a private api
e.g., probe script generates a set of var definitions and assertions
that the parameterized "my-language" make rules use
the probe(1) command and libast pathprobe(3) function handle
probe info maintenance and probe script invocations
> I agree that with mk you can wander into roll-your-own-build hell, but
> given the limitations of the model I thought it was a step forward
> when they threw away *all* predefined rules and variables. These days
> almost all my mkfiles begin with
> <$HOME/lib/mk/builtins
> If I cared about portability (which I may have to again one day)
> the would instead begin with
> <$HOME/lib/mk/`arch-os`
that's good for your portability
but you would not benefit from the portability of how many others in
the world who are working with the same languages/tools
> To me the problem of phase ordering and static dependencies is a much
> more serious limitation of mk. Again, however, it is not enough for
> me to rely on nmake's built-in ability to discover dependencies in,
> say, C source. I work routinely with Haskell, Objective Caml, Lua,
> and other weird stuff. If the magic has to be built in, then it's not
> much use to me and my crowd.
almost all of the user facing nmake specifics are implemented in
probe info
Makerules.mk
Scanrules.mk
there are many ways to extend them, either by direct edits
or by user/project --global rules
along with probe(1) is the little scan language used by the nmake Scanrules.mk
they can be extended with external commands for more complex dependencies
but the idea is to live with static lexical dependency analysis
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
