On Wed, 19 Jul 2017 17:30:53 -0000, Michael Witten wrote:

> On Thu, 20 Jul 2017 00:31:25 +0800, Matt Johnston wrote:
>
>> Thanks for your patches. The Makefile dependency ones look
>> useful, I'll try and double-check them and get them merged
>> in the next week or so. Please if anyone else has comments
>> on these patches make them known - I'm sure there are
>> scenarios I have forgotten.
>>
>> I'm less keen on this options patch series. [cut]
>> 
>> Regarding oldstyle comments, I agree // ones are nicer but
>> it's not too much work to keep the old style working. Most
>> recently the work was done for Tru64's compiler in 2013.61test
>> - Compile fixes for old vendor compilers like Tru64 from Daniel Richard G.
>> 
>> For SMALLCODE and DROPBEAR_CLEANUP I think the current state
>> of options should take precendence over what's documented in
>> CHANGES - looking at commit history it seems they were
>> deliberately changed, just not documented. I'm happy to make
>> historical updates to CHANGES though, I did that recently 
>> "document changed default RSA key size back in 2013.61test"
> 
> I'll produce a revised series that takes these things into account,
> and which will exclude the refactoring.
>
> As for handling scenarios, I've been toying with the idea that
> there should be an automatically run adapter to help people
> convert their setups as seamlessly as possible to the new
> `localoptions.h' system.
>
> [...]

I haven't yet had time to fashion such an adapter, but I do have a fairly
complete patch series to serve as a foundation for that work; my original
series required a great deal more revision than I expected, and I wouldn't
be at all surprised if there is yet more revision necessary, as there are
a large number of moving parts, many of them ancient and twisted in their
own unique ways.

Please inform me of any irritations you find.

There have been numerous minor improvements, clean ups, and generalizations,
but the major thrust is 3 fold:

  * Out-of-tree building works.
    Parallel building works.

  * Dynamic prerequisites work when they are supported by the compiler or
    preprocessor; when the most advanced capabilities are present, this
    extra processing is optimized so that it's virtually seamless.

    Static prerequisites work when dynamic prerequisites are not supported
    by the system, so that everyone is covered; on a system that supports
    dynamic prerequisites, the set of static prerequisites can be updated
    with one simple command:

        make static-prereqs

  * The `localoptions.h' scheme works.

    Options that can be enabled or disabled are now binary switches,
    handled with `#if' constructs, rather than `#ifdef/#ifndef'.

    The set of effective option values can be inspected easily with one
    simple command:

        make show-options

    The results can be saved to a file with something like this:

        make PAGER='cat >/path/to/file.txt' show-options

However, I am beginning to suspect that customization at the level of the C
language (i.e., through `localoptions.h') is not generally adequate enough;
for instance, the `make' command-line variable `MULTI' suggests that a user
should really be cultivating customizations at the level of the makefile
instead (e.g., `localoptions.mk'): The makefile, not the user, would
then be responsible for managing how these customizations are interfaced
with the C code (e.g., by *making* a `localoptions.h' programmatically).
Note, though, that this series does not implement any such makefile-level
configuration, though it does set in place a solid foundation for doing so.

You can grab the series for perusal as follows:

  $ base=a5ec3aca7d9355abf580faf88bd9bf1e871164cb
  $ branch=perusal
  $ git checkout -b "$branch" "$base"
  $ git pull https://github.com/mfwitten/dropbear.git build-and-options/00

Here's how you might delve into it further:

  $ since() { s=$1; shift; git log --reverse ${@:+"$@"} "$s".."$branch"; }
  $ series() { since "$base" "$@"; }
  $ subjects() { series --format=%s; }
  $ numbered() { subjects | awk '{printf("[%7s] ","HEAD~" (22-NR)); print}'; }
  $ numbered
  [HEAD~21] compatibility: Use old-style C comments (`\*...*/')
  [HEAD~20] build: libtommath/makefile.include: `arch' -> `uname -m'
  [HEAD~19] build: Remove unused constructs: `space' and `AC_PROG_MAKE_SET'
  [HEAD~18] build: Upgrade and use `install-sh'
  [HEAD~17] build: Record the value of `PATH' at the time `configure' is run
  [HEAD~16] build: Split flags properly among CPPFLAGS and CFLAGS
  [HEAD~15] build: Wrap `config.h' in an include guard
  [HEAD~14] options: Include `config.h' and use include guards
  [HEAD~13] build: Improve support for out-of-tree builds
  [HEAD~12] build: Remove the `clean' target from `libtommath/Makefile.in'
  [HEAD~11] build: Handle program targets correctly
  [HEAD~10] build: Explicitly mark PHONY targets
  [ HEAD~9] build: Remove targets that are probably dead
  [ HEAD~8] options: Remove public traces of `SCPPROGRESS'
  [ HEAD~7] build: Correct the prerequisites
  [ HEAD~6] build: Move the recipes for `strip', `default_options.h', and 
`localoptions.h'
  [ HEAD~5] options: Make `ifndef_wrapper.sh' more generic
  [ HEAD~4] options: Now that `make -j' works, remove `default_options.h'
  [ HEAD~3] options: Complete the transition to numeric toggles (`#if')
  [ HEAD~2] options: Update the comments that describe the options
  [ HEAD~1] options: Provide `make show-options' for viewing effective option 
values.
  [ HEAD~0] options: Explicitly set each boolean option to `1' or `0'

Many of the commit messages offer detailed commentary, so please consider
consulting them; I would suggest reading them in order:

  $ series -p
  [...]

You can test that each commit can be built in-tree.

  $ srcdir=$(pwd)
  $ configure()
    {
      CPPFLAGS=-DPROGRESS_METER=1 \
        "$srcdir"/configure --enable-bundled-libtom
    }
  $ export PROGRAMS='dropbear dbclient dropbearkey dropbearconvert scp'
  $ build()
    {(
      for r in "$@"; do
         (cd "$srcdir" && git clean -fdx && git reset --hard HEAD &&
         git checkout --detach "$r" && autoconf && autoheader) && 
         configure && make clean && make || { echo Failed: "$r"; break; }
      done
    )}
  $ build $(series --format=%H)
  [...]

You can then test out-of-tree building, too:

  $ revisions=$(since "$branch^{/^build: Improve.*out-of-tree}^" --format=%H)
  $ blddir=/tmp/build
  $ mkdir -p "$blddir" && cd "$blddir"
  $ build $revisions
  [...]

You can also test parallel out-of-tree building:

  $ export GIT_DIR="$srcdir"/.git # So we can use `since' below.
  $ make_cmd=$(command -v make)
  $ make() { $make_cmd -j20 "$@"; }
  $ build $(since "$branch^{/Correct the prereq}^" --format=%H)
  [...]

Maybe check whether installation still works:

  $ make DESTDIR=/tmp/z install
  $ find /tmp/z
  /tmp/z
  /tmp/z/usr
  /tmp/z/usr/local
  /tmp/z/usr/local/sbin
  /tmp/z/usr/local/sbin/dropbear
  /tmp/z/usr/local/share
  /tmp/z/usr/local/share/man
  /tmp/z/usr/local/share/man/man8
  /tmp/z/usr/local/share/man/man8/dropbear.8
  /tmp/z/usr/local/share/man/man1
  /tmp/z/usr/local/share/man/man1/dbclient.1
  /tmp/z/usr/local/share/man/man1/dropbearkey.1
  /tmp/z/usr/local/share/man/man1/dropbearconvert.1
  /tmp/z/usr/local/bin
  /tmp/z/usr/local/bin/dbclient
  /tmp/z/usr/local/bin/dropbearkey
  /tmp/z/usr/local/bin/dropbearconvert
  /tmp/z/usr/local/bin/scp

While you're at it, you can ensure that there really is no more usage
of `#ifdef/#ifndef' when handling an option; this is a nifty little
exercise that employs the new `make show-options' capability:

  $ export GIT_WORK_TREE="$srcdir" # So we can use `git grep' out-of-tree
  $ o=/tmp/options.$$.txt; make PAGER="cat >$o" show-options && cat "$o" |
    {
      ((i=0))
      while read option _; do
        printf .; ((++i == 54)) && { ((i=0)); echo; }
        git grep -l -P "#if[n]def\\s+\\b$option\\b" |
          grep -q -v sysoptions &&
            printf '\n%s\n' Failure: "$option"
      done || printf '\n%s\n' Success\!
    }; rm -f "$o"
    ......................................................
    ......................................................
    .....................................................
    Success!

Sincerely,
Michael Witten

Reply via email to