Glenn,

Thanks for the lengthy note about nmake.
I am quite interested in these issues and intend to pursue
the questions, but at present I am utterly exhausted after
a difficult first semester at a new school.  Not too exhausted 
to send you a few comments however :-)

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.

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`

My 'arch-os' script is the module that hides the secret about how to
discover and name what combination of machine architecture and
operating system my code is running on.

If you have a distribution model to build on, such as for example
always being able to assume that /usr/lib is system-dependent, then it
would be enough just to have

</usr/lib/mk/builtins

but of course even this isn't portable outside Unix-land, so I
understand why (because portability is very important to your group)
you would gravitate toward making the builtins, well, built in.

----------

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.

I'm hoping there might be a research problem here worth pursuing.


Thanks again for the information, and I'm looking forward to asking
more questions later.


Norman
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users

Reply via email to