In D13015#270901, @imp wrote:

In D13015#270839, @bdrewery wrote:

What about all of the make lint support and LINT references in Makefiles?

I'd be more careful about them. Again, that's support for running a linter over the tree vs removing THIS linter from the tree. Orthogonal, but related, problems.

OTOH, it would save a few hundred lines of code in the Makefiles, so what's not to love? I'm sure you'd love that. :)

So Great Idea, but I'm cool with that being a followup commit.

What about all of the make lint support and LINT references in Makefiles?

share/mk/bsd.README:    lint:
share/mk/bsd.README:            run lint on the source files
share/mk/bsd.README:cleandir, depend, install, lint, and tags.  For all of the directories
share/mk/bsd.README:install, lint, and tags.  It has a limited number of suffixes, consistent
share/mk/bsd.README:LINTLIBDIR  Target directory for lint libraries.
share/mk/bsd.README:    lint:
share/mk/bsd.README:            run lint on the source files.
share/mk/bsd.lib.mk:    @${ECHO} building lint library ${.TARGET}
share/mk/bsd.lib.mk:.if !target(lint)
share/mk/bsd.lib.mk:lint: ${SRCS:M*.c}
share/mk/bsd.man.mk:manlint: ${__page}lint
share/mk/bsd.man.mk:${__page}lint: ${__page}
share/mk/bsd.own.mk:# LINTLIBDIR        Base path for lint libraries. [/usr/libdata/lint]
share/mk/bsd.own.mk:LINTLIBDIR?=        /usr/libdata/lint
share/mk/bsd.prog.mk:.if !target(lint)
share/mk/bsd.prog.mk:lint: ${SRCS:M*.c}
share/mk/bsd.subdir.mk:         installfiles installincludes print-dir realinstall lint \
share/mk/bsd.sys.mk:            installincludes lint obj objlink objs objwarn \
share/mk/sys.mk:LINT            ?=      lint

I learned a lot reading this just now.

In D13015#270389, @emaste wrote:

In D13015#270388, @kib wrote:

Aren't they automatically re-generated by somebody else ? I did found them by grepping, and decided not to update because they are not human-editable. Am I wrong ?

Paging @sjg or @bdrewery

Looking at the history in targets/pseudo I see commits to manually chase up previously-removed components.

Approved by: portmgr (bdrewery)

Perhaps config could create a .no_obj file that we check for in src.sys.obj.mk ?

Going to rework this a bit and trim the commit log

Thanks!

Any further comments? I'd like to commit this today.

D12840 obsoletes this change.

D12840 obsoletes this change.

Remove leftover comment to myself

• Simplify detection, no need to create directories, just look for the last missing component and if we can write to that directory.
• Simplify more of the change overall
• Check the wanted OBJDIR rather than only OBJROOT
• Support broken symlinks in the path by recursing on the new link's path, tested with 2 nested links in MAKEOBJDIRPREFIX both with and without missing dirs and writable dirs
• Fix more of the 'make showconfig' support, it actually runs a child with make -dg1 so we need to export to that one
• Add an UPDATING entry

In D12840#267602, @bdrewery wrote:

In D12840#267376, @sjg wrote:

In Junos build we have always used .OBJDIR = ${OBJTOP} for the case ${.CURDIR} == ${SRCTOP} which is why I asserted that it is the correct answer ;-)

How about I do it in a separate commit. This commit doesn't handle MK_AUTO_OBJ, so it is just setting .OBJDIR if possible to an existing directory. I am keeping the current behavior of .OBJDIR==.CURDIR when there's no OBJDIR yet in SRCTOP. I do prefer having a valid .OBJDIR to use even if 'make obj' hasn't ran yet. So I am open to doing it, I just think it's a behavior change that deserves its own commit.

Fix WITHOUT_UNIFIED_OBJDIR to actually work and only apply it at top-level like was done historically.