[DTrace-devel] [oracle/dtrace-utils] c9d864: build: overridable configuration variables

Fri Jan 26 14:03:17 UTC 2024

  Branch: refs/heads/nix/review/configury
  Home:   https://github.com/oracle/dtrace-utils
  Commit: c9d864c79dfc557c475806b331ece6007cdd2fe2
      https://github.com/oracle/dtrace-utils/commit/c9d864c79dfc557c475806b331ece6007cdd2fe2
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Makeconfig
    M Makeoptions

  Log Message:
  -----------
  build: overridable configuration variables

The Makeconfig checks are purely compile-time, so should always work: but
sometimes there are multiple choices, and if they choose an option the user
dislikes, the user might well want to override them (e.g. picking FUSE 2
even though FUSE 3 is already present).

This change causes every check-* invocation in Makeconfig to respond to
HAVE_* make variables set on the command line, and also to produce a line in
'make help' of the general form

HAVE_LIBSYSTEMD=[yes/no]	Override check for presence of sd_notify in libsystemd

etc.

(The escaping in make-override-help to figure out how many tabs to insert to
properly align the help will make your eyes bleed. One $ for every nested
$(eval $(call ...)): thank goodness they're all at the same level!)

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>

  Commit: 0062a4111f06d3b039e0ace56b3dffbcac45dfe3
      https://github.com/oracle/dtrace-utils/commit/0062a4111f06d3b039e0ace56b3dffbcac45dfe3
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Makeconfig
    M Makeoptions

  Log Message:
  -----------
  build: support make help-overrides and make help-options

These provide only *part* of the make help output, and as a side
benefit shuffle the output into a somewhat better order.

Used by the upcoming configure script to avoid needlessly
reduplicating help text.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>

  Commit: d624055f20fa3eb035d1b7aa704e90e5c77c8df3
      https://github.com/oracle/dtrace-utils/commit/d624055f20fa3eb035d1b7aa704e90e5c77c8df3
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M GNUmakefile

  Log Message:
  -----------
  build: avoid building config.mk unnecessarily

'make help' and similar targets in a clean tree can take quite a
long time, and can even fail(!), because the unconditional inclusion
of config.mk forces all the Makeconfig machinery to run even if we
are doing nothing that might ever need any of it.

Include it only when we're not asking for things like help,
make dist, make clean and things like that.  (A surprising amount
does depend on config.mk and more will depend on it once we start
to optionally bake installation paths into it, but this subset
seems likely never to need it.)

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>

  Commit: 79df331142c5c6ae7a0e56d159934427eea7f37c
      https://github.com/oracle/dtrace-utils/commit/79df331142c5c6ae7a0e56d159934427eea7f37c
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M GNUmakefile

  Log Message:
  -----------
  build: avoid needless re-executions

The USER_UID and DUMPCAP_GROUP variables are recursively assigned, but
contain shell execution. It's not terribly expensive execution, but these
variables are substituted into every compile line, so they're executed
dozens of times, even though their values will never change.

Move them into immediate assignment (which makes DUMPCAP_GROUP a bit more
complex to allow it to be overridden).

This speeds up near-do-nothing runs like 'make help' so that they take only
about 1/10s now, which is acceptably fast.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>

  Commit: 03b3bec964963da460af77fb0235a084693e97c3
      https://github.com/oracle/dtrace-utils/commit/03b3bec964963da460af77fb0235a084693e97c3
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Makeconfig

  Log Message:
  -----------
  build: only touch .dir.stamp if it doesn't already exist

This stops its date being continuously updated, forcing configure
retests all the time.  Now it serves its intended purpose of causing
configure retests only if .config was deleted (as is done by e.g.
make clean).

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>

  Commit: aa4215cf3b3983c28113f44b98cd3315e3264f47
      https://github.com/oracle/dtrace-utils/commit/aa4215cf3b3983c28113f44b98cd3315e3264f47
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Makeconfig

  Log Message:
  -----------
  build: force regeneration of config.{h,mk} when configure options change

Now that we are actually rerunning configure tests only when needed, we need
to force regeneration of config.h more reliably (we can't depend on the
stamp file to do it for us, since that is now updated only when the
directory as a whole is deleted).  Just have the individual configure tests
delete the generated accumulated config files, forcing regeneration with the
new content produced by that rule.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>

  Commit: 53c6b1c0cc6a47427b854998a4440cf9a6fc68de
      https://github.com/oracle/dtrace-utils/commit/53c6b1c0cc6a47427b854998a4440cf9a6fc68de
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Makeconfig

  Log Message:
  -----------
  build: support make help-overrides-option and help-overrides-header

Add a make help-overrides-option which reports certain configuration
variables (those relating to external libraries) in a different format, as
if they were configure options.

HAVE_FOO_BAR is printed as

--have-foo-bar	...

This is used by the configure script to provide two formats for such options
(expected to be more necessary when they are needed at all, due to the lack
of useful automatic replacements for such libraries), via ENV_OVERRIDES or
--configure-options=.

We split the header emitted at the top of make help-overrides off into make
help-overrides-header because the configure script will want to emit the
header before the help-overrides-option output (which is printed first).

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>

  Commit: d32bb45894dc84022ce22e31966c6e3be5ae4e0d
      https://github.com/oracle/dtrace-utils/commit/d32bb45894dc84022ce22e31966c6e3be5ae4e0d
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M GNUmakefile
    M README.md
    A configure

  Log Message:
  -----------
  build: add configure script

This serves three purposes:
 - let you bake configuration into build/config.* so that you don't
   need to specify the same arguments to make repeatedly
 - provide a somewhat familiar interface to builders
 - provide more documentation for bits of the build configuration
   which there was no place to document (notably Make variables
   overridden by the user, which were documented only
   intermittently in comments in the top-level GNUmakefile).

It is *not* generated by Autoconf but is a short and hopefully
comprehensible shell script.

Internally it's fairly boring.

Overrides of makefile variables go into a new config-vars.mk, which is
written as a unit, since their construction is very cheap and they don't
need the variable-by-variable, test-by-test construction process used for
variables that end up in config.{mk,h}.

Some of the help (for all the Makeconfig overrides) is printed by calling
"make help-overrides", which ultimately derives it from the Makeconfig
itself.  (Unfortunately I can't see a way to generate the actual
write_config_var invocations from the same place, so there's still a bit of
extra work to do when you add new Makeconfig tests.)

The rest of the "make help" -- and really most of the configure script -- is
duplicative of stuff already in the GNUmakefile, but I can't see a way to
automate its generation without ending up with *way* more automation than we
have duplicated code here.

In the GNUmakefile, the biggest impact is making all the paths normal
recursively evaluated variables, so that they can pick up
configure-generated paths (which are defined later), and moving most of the
rest of the non-configure-modified variables down below the inclusion of
config-vars.mk.  This gives the desired properties for defaulting:

 - doing nothing causes the assignments in the Makefile to kick in
 - defining stuff via configure causes them to be overridden by
   further assignments in the config-vars.mk (which values are then
   picked up by the moved-down assignments
 - passing stuff on the make command line does what that normally
   does, and suppresses the corresponding in-makefile variable
   assignments, both in GNUmakefile itself and in config-vars.mk,
   thus overriding both the defaults and configure-generated paths

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>

  Commit: 4ac1eb95ce083ff48a299ad05672e0966c8c48ca
      https://github.com/oracle/dtrace-utils/commit/4ac1eb95ce083ff48a299ad05672e0966c8c48ca
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M GNUmakefile
    M libproc/mkoffsets.sh

  Log Message:
  -----------
  build: consistently respect CC env var if set

We are very close to making this work: only two places (the top-
level makefile's detgermination of the native bitness, and
the code that does the same thing in libproc/mkoffsets.sh) needed
any changes.

(The testsuite refers to /usr/bin/gcc all over the place, and is
not changed in this commit.)

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>

Compare: https://github.com/oracle/dtrace-utils/compare/cdeee4b3f328...4ac1eb95ce08