Bug in make(1)?

[Terry Lambert]

Pawel Jakub Dawidek wrote:
> On Thu, Apr 03, 2003 at 01:50:59PM -0800, Marcel Moolenaar wrote:
> +> Because you told make(1) to by virtue of including bsd.prog.mk
> +>
> +> OBJS is derived from SRCS by replacing the extension. If SRCS
> +> contains foo/bar.c, OBJS will contain foo/bar.o...
> 
> Yes, but take a look on compilation process. When file is compilated
> '-o' isn't specified (gcc -c test/tst.c), but when executable file is
> produced, gcc looks for tst.o in test directory (gcc -o tst test/tst.o).
> And IMHO if gcc want to look for objects somewhere it should put them
> there, so: gcc -o test/tst.o -c test/tst.c. Sometimes it is hard to
> change.

The real problem is that the object directory is often intentionally
not the source directory.  The libc_r build procedure works this way.

You don't want to list source objects by path; you want to use
subdir Makefile's, and the constructs that are there to support
obtaining sources from alternate directories.

You should look at the ".PATH:" directive.  For the "test/tst.c"
case, probably the correct thing to do is use something like:

	.PATH:	${.CURDIR}/test

	...
	# source files from test/*; if names collide, you should be
	# using a library, instead of compiling direct subdir sources
	SRCS+=	tst.c

	...
	.include <bsd.prog.mk>

This will cause tst.o to both be crated, and referenced, from the
directory in which the Makefile resides, instead of mixing references
to the subdirectory "test".

FWIW: I've been annoyed by the behaviour, as well; however... I
understand how, if one is using an OBJDIR, that using subdirectories
below the directories, without sub-Makefiles to create the objects,
could make the build system parallel object directory creation fail.

-- Terry