Axe xlint.

[kib]

Summary

xlint is currently a fossil. We have much more useful and alive tools to do now what xlint did twenty years ago.

I did not cleared some stuff which makes lint operational, in x86/include, but I might do it as followup. The x86/include/ucontext.h and _types.h hacks made to please lint was the main reason for my initial proposal to classify xlint as obsolete and to remove it.

Also I do not intend to clear sccs ids.

[emaste]

LGTM.

There are also adjustments to make in targets/pseudo/hosttools/Makefile.depend.host and targets/pseudo/userland/Makefile.depend

[imp]

The only quibble I have with this is the 20 years bit... lint was doing this 25 years ago, and was still useful 15 years ago... So maybe 20 years is a good average for the two and I shouldn't quibble.

And don't let my quibbles get in the way here: xlint has become a bigger burden than benefit.

[kib]

In D13015#270376, @emaste wrote:

There are also adjustments to make in targets/pseudo/hosttools/Makefile.depend.host and targets/pseudo/userland/Makefile.depend

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 ?

[emaste]

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.

[pfg]

This is all fine and well but we still also have a bunch of
#if defined(lint)
all over the tree

Perhaps we should at least clean the lint cruft from sys/sys/cdefs.h

[kib]

In D13015#270406, @pfg wrote:

This is all fine and well but we still also have a bunch of
#if defined(lint)
all over the tree

Perhaps we should at least clean the lint cruft from sys/sys/cdefs.h

I specifically mentioned this in the explanation. I do not want to touch this now, and limited cleanup might be done later. I only want to remove the lint itself and lint libraries build as the first step.

[imp]

In D13015#270406, @pfg wrote:

This is all fine and well but we still also have a bunch of
#if defined(lint)
all over the tree

Perhaps we should at least clean the lint cruft from sys/sys/cdefs.h

That stuff is also there to support not only xlint, but other external linting programs. That's an orthogonal issue to this. The external linting programs, though, likely aren't relevant enough. The last references I saw to people fixing bugs with them are only about 10 years old.

And cleaning up sys/sys/cdefs.h is as well... There's much history there that's interesting for the software archeologists, but not really relevant today.

Neither issue should be conflated with this stuff, imho, though both may be important in their own right.

[bdrewery]

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.

targets/ dir is entirely manual.

Compare:

~/git/freebsd # head -n 2 bin/sh/Makefile.depend
# $FreeBSD$
# Autogenerated - do NOT edit!

~/git/freebsd # head -n 3 targets/pseudo/userland/Makefile.depend
# $FreeBSD$

# This file is not autogenerated - take care!

So yes please remove references in targets/.

[kib]

Remove lint from targets/

[pfg]

In D13015#270408, @kib wrote:

In D13015#270406, @pfg wrote:

This is all fine and well but we still also have a bunch of
#if defined(lint)
all over the tree

Perhaps we should at least clean the lint cruft from sys/sys/cdefs.h

I specifically mentioned this in the explanation. I do not want to touch this now, and limited cleanup might be done later. I only want to remove the lint itself and lint libraries build as the first step.

Indeed you did, and it is difficult to say how far should further cleanups go (even the code in contrib/ has such definitions).
Nevermind, I mentioned it.

[jhb]

I would love to remove all the '#ifdef lint' bits in the future.

[kib]

In D13015#270755, @jhb wrote:

I would love to remove all the '#ifdef lint' bits in the future.

I certainly plan to do this for x86/include after some time, this is the main motivation for the proposal. I am not so certain about sys/cdefs.h, but perhaps it is reasonable.
Definitely I do not want to touch all the sccs id, although they are useless, I believe.

[kib]

In D13015#270765, @kib wrote:

I am not so certain about sys/cdefs.h, but perhaps it is reasonable.

The #ifdef lint in sys/cdefs.h or sys/types.h is clearly non-compliant with ANSI C and stomps on the user namespace.

[bdrewery]

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

share/mk/bsd.lib.mk:    ${LINT} ${LINTLIBFLAGS} ${CFLAGS:M-[DIU]*} ${.ALLSRC}
share/mk/bsd.lib.mk:    ${LINT} ${LINTFLAGS} ${CFLAGS:M-[DIU]*} ${.ALLSRC}
share/mk/bsd.prog.mk:   ${LINT} ${LINTFLAGS} ${CFLAGS:M-[DIU]*} ${.ALLSRC}
share/mk/bsd.suffixes.mk:       ${LINT} ${LINTOBJFLAGS} ${CFLAGS:M-[DIU]*} ${.IMPSRC} || \
share/mk/bsd.suffixes.mk:       ${LINT} ${LINTOBJFLAGS} ${CXXFLAGS:M-[DIU]*} ${.IMPSRC} || \
share/mk/sys.mk:LINT            ?=      lint

(only grepped share/mk there but there's a lot more.)

[imp]

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.

[bdrewery]

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.

Well I'm not usually interested in removing code for the sake of removing it. It just seems that if we remove the linter that the code may not be useful anymore. Is there a replacement linter in ports that is more useful for these targets?

[imp]

In D13015#270902, @bdrewery wrote:

Well I'm not usually interested in removing code for the sake of removing it. It just seems that if we remove the linter that the code may not be useful anymore. Is there a replacement linter in ports that is more useful for these targets?

In the past, it was possible to use other lint progarms than xlint in the tree. I don't know if that's still the case since many of those programs were commercial in nature and the companies offering them I think disappeared a while ago...

I tend to agree that they would now become effectively useless. I'll not stand in the way of their removal. But if kib@ wants to get the first step in before proceeding to removing this stuff, I think that's a fine way to go.

[kib]

In D13015#270905, @imp wrote:

In D13015#270902, @bdrewery wrote:

Well I'm not usually interested in removing code for the sake of removing it. It just seems that if we remove the linter that the code may not be useful anymore. Is there a replacement linter in ports that is more useful for these targets?

In the past, it was possible to use other lint progarms than xlint in the tree. I don't know if that's still the case since many of those programs were commercial in nature and the companies offering them I think disappeared a while ago...

I tend to agree that they would now become effectively useless. I'll not stand in the way of their removal. But if kib@ wants to get the first step in before proceeding to removing this stuff, I think that's a fine way to go.

It is nth attempt to entangle the lint(1) removal and the possible further removal of the *lint support* from the tree. I will not mix them. Yes, I want to do some followps, but my interest and competence are mostly directed toward sys/sys and x86/include.

[brooks]

xlint has been useless for years and has some of the worst code quality in the base system. Its removal is long overdue.

[wblock]

Please remember to update .Dd in hier.7 and style.9.