texinfo breakage

[Bruce Evans]

On Thu, 24 Jul 2003, Ruslan Ermilov wrote:

> On Thu, Jul 24, 2003 at 04:39:14AM -0700, Kris Kennaway wrote:
> [...]
> > Since you're waiting on me to test those two patches, here are the
> > rest of the ports that are currently broken due to those bsd.lib.mk
> > changes so you can develop patches for those as well (there will
> > probably be others that turn up later as broken dependencies are
> > fixed):
> >
> > ja-ming-0.1.5
> > ja-tcl-7.6
> > libU77-2.6
> > libcache-1.1.0
> > libgmp-2001.08.07
> > mlan3-1.00
> > ranlib-1.0
> >
> An updated patch is attached.  I did not fix the mlan3-1.00 as
> the port's patch is unmaintainable, please ask its maintainer.
> Also, I've given up on libgmp-2001.08.07.  This port (which is
> what we have in RELENG_4 as src/gnu/lib/libgmp/) is subject to
>
> # Grrr. This package contains modules in separate subdirs that have the
> # same name.
>
> in its makefile, so I cannot fix it easily by simply converting
> path prefixes in SRCS into the .PATH: dependency list, as for
> other ports.

I think the full pathnames to sources in the makefiles are just style
bugs except here.

> So now we need to decide: do we want to support bogus SRCS with
> paths in bsd.{prog,lib}.mk or not.  Previously, we only supported
> it in bsd.lib.mk, but not in bsd.prog.mk.  Also, POSIX standard
> suffix transformation rule for .c.o looks like this:
>
> .c.o:
> 	${CC} ${CFLAGS} -c ${.IMPSRC}
>
> That is, no -o for cc(1).  We cannot fix POSIX rules, and if
> we fix the non-POSIX rules in sys.mk (as shown in another
> attached patch), the two sets of rules will differ even more.
> OTOH, there's no harm in having these additional -o's in the
> normal case of SRCS without path prefixes.  So, what do we
> do with this?  Should I commit the attached patch to sys.mk,
> or should I just fix this makefile to use another .c.o rule?

There is harm for the general case of sys.mk.  Apart from being
incompatible with the POSIX rules, it is just wrong to build
targets in the same directories as the sources in general.
"-o ${.TARGET}" does this (${TARGET} for source .../foo.c is
.../foo.o).  I think sys.mk needs to use "-o ${.PREFIX}" or
"-o ${.TARGET:T}" if it uses -o at all, although for .c.o this
just gives the same behaviour including exposing bugs as not
using -o.  Most or all of the current uses of "-o ${TARGET}"
are wrong.

Specialized makefiles can reasonably want to build objects outside
of the object directory, but this is very un-[Free]BSD-makefile-like
so I wouldn't want to support it in bsd.*.mk.  I think it is mostly
accidental that bsd.lib.mk has some support for it.

Bruce