On Sat, 29 Nov 2008 21:53:35 -0500 Norman Ramsey wrote:
> It looks to me as if the best solution is probably to write the test
> scripts using nmake (or mk) with ksh in the action blocks (resp. recipes).
> I just revisited the nmake web pages and I left with the same
> impression I always have---the claimed features are most alluring, yet
> there is a little more complexity there than I can easily wrap my head
> around. I always wind up falling back to Andrew Hume's mk, which to
> my way of thinking is the simplest and best engineered modern Make.
> I particularly admire Andrew's decision that mk variables are shell
> variables, so there's no messing around with $(funny-character).
> $target instead of $(<) for example.
> If anybody can recommend what to read to learn better about nmake, I
> would like to know. Anything that can eliminate autoconf and
> configure and that can handle recursive make well is worth learning.
sorry it took so long to get back on this
mk provides a concise model, more along the lines of the original make
it processes makefiles in two distinct phases
the first generates the complete dependency graph
once this is done there are no further changes to the graph
the second phase processes that graph
there are no mk-specific variable edits, so there is no loss just using
shell var syntax
the complexity differences between mk and nmake boil down to makefile
portability
in mk just about everything must be specified explicitly
and if not explicit then they must be parameterized via
programmer specific convention
consider the pattern metarules and makefile assertions / recipes
involved in compiling *.c to object files and then to an a.out
on some systems the object suffix is .o, on others .obj
on some systems executables have no suffix, on others .exe
on some .exe suffix systems 'cc -o foo' creates foo, on others foo.exe
how do you capture this in one makefile?
you probably don't, and and probably use some manual config/initialization
before the first mk
add in static library, shared library, and dll naming conventions
and you can end up in morass pre- and post- mk
sort of a roll your own gnu build system
nmake (mostly via its makerules) takes a different approach by abstracting
most user level assertions into "ultimate-target depends on these terminal
source files", where terminal means not-generated
so the assertion
hello :: hello.c
works on all systems
try that one line makefile on uwin and run
nmake hello
nmake hello.exe
(on uwin nmake => /usr/bin/nmake != microsoft nmake)
library assertion are also portable
mylib 1.2 :LIBRARY: a.c ... z.c -lsocket -lyourlib
to generate a shared lib / dll in addition to a static archive add this
CCFLAGS += $(CC.DLL)
or
CCFLAGS = $(CC.OPTIMIZE) $(CC.DLL)
run this to see the compiler specific information (e.g., CC.DLL)
probe -l C make cc
since an nmake action can be either for sh or for nmake, the dependency
graph may change as the nmake execution progresses (via make actions that
add more target assertions)
with nmake recursion is not considered harmful
here is the ast and uwin setup
src
lib cmd
(leaves) (leaves)
the src, src/lib and src/cmd directories contain a makefile with this one
assertion
:MAKE:
nmake run in any dir will build, in the proper order, the internal leaves in
that
subtree in the proper order
this list the recursion order, with - separating concurrent groups
:MAKE: does a directory ordering based on the makefiles in the subtree
these general rules must be followed in the leaves
(1) install of a library makes the library and headers visible to the entire
tree
install of a command makes the command visible to the entire tree
(2) leaves reference their own files or installed files (not ../sibling/foo.h)
(3) all library dependencies must be asserted (-lfoo ... -lbar)
(4) command assertions use ::, library assertions use :LIBRARY:
with this setup leaf dirs can be added incrementally, and they will be
built in the proper order
to see this in action download the ast-open package or the uwin source package
and look at the Makefiles/Nmakefiles
the best nmake configurations confine the complexity to the rules files
other things that set nmake apart (but also add complexity) are state retention
between nmake invocations, implicit prerequisite scanning (e.g., #include),
variable values as prerequisites
here is an overview
http://www.research.att.com/~gsf/nmake/
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
