There is a suspicious condition in SuffUpdateTarget code that looks wrong
on the first sight. When removing it though, make allocates huge amounts
of memory. To stop freezing the whole machine in this situation, limit
the total memory.
The limit of 200000 has been determined experimentally on NetBSD 8.0
x86_64. With a limit of 100000, make wouldn't even start. 100 MB of
memory is really a lot for such a simple program that according to top(1)
only needs 8 MB. But 200 MB is still better than 5 GB.
Since the Makefile is used on other platforms as well, via the bmake
distribution, and since every operating system has its own list of ulimit
options, make this configurable.
The previous code with the extra boolean variable was a brain-twister
since the responsibility of freeing the memory was distributed over 3
different functions.
One notable thing is that there is no debug output when adding a
transformation rule like ".c.o", which means that these rules don't end
up in the global allTargets variable.
This may or may not be intentional. It seems not intentional since this
is one of the causes for the suff-rebuild test to behave unexpectedly.
As long as it is not clear why this test fails, it's better to have the
debug log available, both for reading it and for getting notified if
any behavior in this area changes.
Additionally:
- Make it easier for the reader to learn which keywords can be used
multiple times
- Use multiple "userconf" lines in the EXAMPLES section, conveniently
listing the current DRM drivers that a user might need to disable to
troubleshoot "blank screen after boot" issues.
It was unclear what the ellipsis referred to. It was meant to refer to
the function call Lst_Free, but that was not necessarily obvious to a
casual reader.
The "Removing suffix" is not covered by the current tests. It would be
best if that code were unreachable at all, since a reference count of -1
doesn't make sense.
The prefix "gs" came from a time when SuffScanTargets was called via
Lst_ForEach, passing it a struct GNodeSuff. The "gs" had just been the
abbreviation for "GNode + Suff", which was already non-expressive. On
top of that, the struct had a third field "r", also with an unclear name,
which was not even mentioned in the name of the struct.
For now, just remove the needless prefix since it has absolutely no
meaning anymore. Maybe it will become clear what the "r" was supposed to
mean, it could be some kind of "result".
thorpej