[DTrace-devel] [oracle/dtrace-utils] 77bfc1: build: get the architecture from gcc -dumpmachine, ...

[Nick Alcock]

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

  Changed paths:
    M GNUmakefile

  Log Message:
  -----------
  build: get the architecture from gcc -dumpmachine, not uname -m

This lays the groundwork for future support of cross-compilation.
It doesn't mean we do support it, but it's the first necessary
prerequisite for such support.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Eugene Loh <eugene.loh at oracle.com>


  Commit: e04bd4044dd673916dcaa4431b71fb0226f5eefb
      https://github.com/oracle/dtrace-utils/commit/e04bd4044dd673916dcaa4431b71fb0226f5eefb
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-15 (Mon, 15 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: 3a532128a483398836c85884542df2a2655c43e3
      https://github.com/oracle/dtrace-utils/commit/3a532128a483398836c85884542df2a2655c43e3
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-15 (Mon, 15 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: a866e616ea5dc76eab698719574a7d6da4eed009
      https://github.com/oracle/dtrace-utils/commit/a866e616ea5dc76eab698719574a7d6da4eed009
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-15 (Mon, 15 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: 35906979e682dabec45bc551ceb69e91e788425c
      https://github.com/oracle/dtrace-utils/commit/35906979e682dabec45bc551ceb69e91e788425c
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-15 (Mon, 15 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: baf29df4d68df8a5f2698fe09a816b091fdf89cf
      https://github.com/oracle/dtrace-utils/commit/baf29df4d68df8a5f2698fe09a816b091fdf89cf
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-15 (Mon, 15 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: 232eeeed403c7bfe4858cc03ef29b267ef7664bf
      https://github.com/oracle/dtrace-utils/commit/232eeeed403c7bfe4858cc03ef29b267ef7664bf
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-15 (Mon, 15 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: cdeee4b3f328075db2ac50e720c999fe0c04bb87
      https://github.com/oracle/dtrace-utils/commit/cdeee4b3f328075db2ac50e720c999fe0c04bb87
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2024-01-15 (Mon, 15 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>


Compare: https://github.com/oracle/dtrace-utils/compare/0191e4b578d2...cdeee4b3f328