On Thu, 16 Sep 2004 01:57:52 +0200, mouss writes:
>sure, but... it would be better to have a way to "send" objects to a 

You can do that if you want to write the entire makefile (or macro
infrastucture) from scratch.
Most of us prefer to re-use well tried & tested functionality.
Ie. the bsd.*.mk macros get used every day to [cross-]build large
systems for multiple architectures.

>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).

For some value of "feasible" sure.

>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 

All true.  Conversely, most makefile writers are not sufficiently
pedantic to ensure that nothing gets dribbled into the src directory,
so the chdir first approach helps to successfully build from read-only
src.

>and extermely humble opinion, path and friends are rarely the solution 
>to getting to the source.

What can I say - it works and has been doing so for many years.

>./obj isn't my preferred way. I like keeping the src tree clean (this 
>allows things like "tar sources", "cleanall=rm -rf", 

Yep, I don't use it either.  Like I said there are lots of options.
The simplest is something like MAKEOBJDIRPREFIX=/var/obj
Though personally, I use MAKEOBJDIR='${.CURDIR:S,${SRCTOP},${OBJTOP},}'

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

Sure, I've done the same.  But I prefer bmake ;-)

--sjg