Simon J. Gerraty wrote:
> 
> The best way to use BSD make is with the share/mk/*.mk macros.  A typical
> makefile should be no more complex than:
> 
> PROG=foo
> SRCS=foo.c parser.y lexer.l
> 
> .include <bsd.prog.mk>
> 
> of course, that's far from your originally posted setup ;-)
> in which (IIRC) you had src's in . and wanted to compile to dir/*.o
> which is pretty much the opposite of the way bmake works.
> 
> I.e it's best (causes fewer headaches) to compile to . and have srcs found
> elsewhere via .PATH:  eg.
> 
> .PATH: /my/src /my/other/src
> SRCS= foo.c goo.c
> 

sure, but... it would be better to have a way to "send" objects to a 
specified dir, without resorting to path/vpath and friends, because 
these bring their cousins... when simultaneously building for differents 
OSes/variants/etc it helps to be able to just do -o ${build_dir}/%.o.
I didn't check the details, but I'm pretty sure this is feasible with 
bmake (but of course, I may be wrong).

> will find /my/other/src/foo.c and /my/src/goo.c (assuming that's where 
> they live) and the normal suffix rules will compile them to foo.o and goo.o
> 

which means you chdir before compiling and adding the src dir to path, 
and sometimes path has other dirs, and sometimes we don't like path to 
contain anything (because of possible use of same filenames). in my very 
and extermely humble opinion, path and friends are rarely the solution 
to getting to the source.

> By default bmake will automatically chdir to ./obj (if it exists) before 
> generating but some folk don't like that.  There are lots of options though
> and if you don't mind magic you can do pretty slick stuff.

./obj isn't my preferred way. I like keeping the src tree clean (this 
allows things like "tar sources", "cleanall=rm -rf", 
"save_previous_build=mv ..", ...). Also, permissions might get in your 
way if you need to build in the same dir. and what if you wanna build in 
a different fs (one with lot of space but that you don't need to backup).

> 
> GNU make can of course do many of the same things - but you'd have to write
> a lot more makefile.
> 

i've written some based on bsd.mk files. so the beauty of bsd.mkfiles 
principle (or call it pattern) goes beyond bmake...