Re: gcc10 with Ada support added to wip

[Roland Illig <roland.illig%gmx.de@localhost>]

Am 05.11.2021 um 09:16 schrieb Fernando Oleo Blanco:
> Regarding the pkglint issues. I based gcc10-aux on gcc10. pkglint lists
> the following when run on lang/gcc10 (from current):


> WARN: Makefile:182: Invalid make target "||".

This is an ugly hack, and I there should be at least a comment
explaining why '|| ${TRUE}' is needed and useful. Right now it looks as
if any errors are suppressed without a proper reason. Adding an
explanation does not fix the pkglint warning though.

> WARN: Makefile:182: The user-defined variable MAKE_JOBS is used but not
> added to BUILD_DEFS.

This warning is wrong. MAKE_JOBS is a build-only variable that under
normal circumstances has no effect on the resulting binary, so it
doesn't need to be listed in BUILD_DEFS.

> WARN: README.html: Invalid symlink name.

pkglint currently has no explanation for this warning, and I had to look
it up in the code what pkglint wants to say here. The only symlinks that
pkglint ever expects are those to WRKDIR, which are usually named 'work'
or 'work.*'. I had expected that a simple 'make clean' would remove this
file, but it is still there. Anyway, there is nothing to worry about.

> WARN: options.mk:32: Variable names starting with an underscore
> (_GNU_INCLUDE_DIR) are reserved for internal pkgsrc use.

The lang/gcc* packages are definitely ones that are close to the pkgsrc
infrastructure, so it is OK for them to have a few variable names
starting with underscore. I'll add an exception to pkglint for these
directories and a few others.

> WARN: options.mk:55: Variable names starting with an underscore
> (_libdir_) are reserved for internal pkgsrc use.

Variables in .for loops don't need the underscores since the naming
convention for normal variables is to be uppercase, so there won't be a
normal variable of the same name. In lang/gcc9 I named it simply 'dir'
when I cleaned up the code in January 2020. Back then, I didn't copy
lang/gcc8 exactly to see which of the patches were still necessary. I
had left out some features, that's why lang/gcc10 was based on lang/gcc8
in the end.

> WARN: options.mk:3: The buildlink3 identifier "gcc10" should be the same
> as the options identifier "${GCC_PKGNAME}".

That was another cleanup that I did in gcc9 since it makes the code
easier to read. It doesn't make updating to a newer GCC version more
difficult since the word 'gcc10' is as easy to search as '${GCC_PKGNAME}'.

To summarize, some of the warnings are worth fixing and some aren't.
I'll take care of fixing the wrong warnings in pkglint.

Roland