stale .depend during -HEAD builds?

Discussion:

Adrian Chadd

2015-06-19 13:08:21 UTC

Hi Simon/others,

Is this a fallout from the meta mode changes?

make[4]: /home/adrian/work/freebsd/head-embedded-2/src/../obj/mips//mips.mips/usr/home/adrian/work/freebsd/head-embedded-2/src/usr.sbin/praliases/.depend,
78: ignoring stale .depend for
/home/adrian/work/freebsd/head-embedded-2/src/../obj/mips//mips.mips/usr/home/adrian/work/freebsd/head-embedded-2/src/lib/libsmdb/libsmutil.a

-a

Simon J. Gerraty

2015-06-19 15:21:47 UTC

Permalink

Post by Adrian Chadd
Is this a fallout from the meta mode changes?

Without more detail, its hard to be certain.

Post by Adrian Chadd
make[4]: /home/adrian/work/freebsd/head-embedded-2/src/../obj/mips//mips.mips/usr/home/adrian/work/freebsd/head-embedded-2/src/usr.sbin/praliases/.depend,
78: ignoring stale .depend for
/home/adrian/work/freebsd/head-embedded-2/src/../obj/mips//mips.mips/usr/home/adrian/work/freebsd/head-embedded-2/src/lib/libsmdb/libsmutil.a

Is that what your objdirs normally look like?

The message from make is standard bmake behavior.
An unresolved and unresolvable dependency learned from .depend
is ignored, in case it is just stale data.
If it really is needed the build will fail anyway, but in 90% of cases
it is just stale data and the build sails happily on.

Normally you would see this sort of thing after some sort of tree re-org
(eg things getting renamed or removed).

Very handy for update builds, especially if doing any form of auto
depend (which usually means depends lag by a build)

Adrian Chadd

2015-06-19 15:39:43 UTC

Permalink

Post by Simon J. Gerraty

Post by Adrian Chadd
Is this a fallout from the meta mode changes?

Without more detail, its hard to be certain.

Is that what your objdirs normally look like?

Yup:

github.com/freebsd/freebsd-wifi-build

You can use that to generate MIPS AP images using freebsd-head ,and
the obj paths are relative.

Post by Simon J. Gerraty
The message from make is standard bmake behavior.
An unresolved and unresolvable dependency learned from .depend
is ignored, in case it is just stale data.
If it really is needed the build will fail anyway, but in 90% of cases
it is just stale data and the build sails happily on.
Normally you would see this sort of thing after some sort of tree re-org
(eg things getting renamed or removed).
Very handy for update builds, especially if doing any form of auto
depend (which usually means depends lag by a build)

Ok. I just didn't see it until I updated my local MIPS tree to include
the meta make stuf, (and did kill obj/root.)

-a

Masao Uebayashi

2015-06-22 07:38:21 UTC

Permalink

Post by Simon J. Gerraty

Post by Adrian Chadd
Is this a fallout from the meta mode changes?

Without more detail, its hard to be certain.

I wish make(1) had a flag, like cc's warning level, that controls
strictness, and failed when a stale depend is found.

Adrian Chadd

2015-06-22 16:21:42 UTC

Permalink

That's like, 30 lines of C all up, including modifying usage(). You
should totally add it.

-a

Post by Masao Uebayashi

Post by Simon J. Gerraty

Post by Adrian Chadd
Is this a fallout from the meta mode changes?

Without more detail, its hard to be certain.

I wish make(1) had a flag, like cc's warning level, that controls
strictness, and failed when a stale depend is found.

Simon J. Gerraty

2015-06-22 15:52:04 UTC

Permalink

Post by Masao Uebayashi

Post by Simon J. Gerraty
If it really is needed the build will fail anyway, but in 90% of cases
it is just stale data and the build sails happily on.

I wish make(1) had a flag, like cc's warning level, that controls
strictness, and failed when a stale depend is found.

For this case that would force you to have to clean your tree
every time someone moves/renames a header - very tedious.

This particular behavior works very well in conjunction with autodep
(whether via compiler flags like -M or other means) where the content of
.depend actually relects the last build not the one being done.