[Boost-build] Major breakage in gcc derived toolsets

Subject: [Boost-build] Major breakage in gcc derived toolsets
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-12-30 21:03:44

AMDG

The recent refactoring of the gcc family broke darwin:

- darwin.setup-address-model is no longer called for compiling,
  which means that compiling uses the default gcc options and
  ignores address-model=32_64 and architecture=combined.  darwin.link,
  on the other hand, passes /both/ the options from darwin.jam and
  those specified in gcc.jam, because the gcc setup code now
  runs unconditionally and bypasses darwin.jam's attempt to override it.
- The toolset.requirements for setting linker-type in gcc.jam fails
  if there are any extra requirements in the condition, because
  condition uses a different separator.  (',' for toolset.requirements,
  '/' for toolset.flags) (fixed)
- The linker-type and platform subfeatures for clang and intel can
  have the same value (darwin), which results in silent misbehavior,
  when expanding subfeatures, because the compressed subfeature format
  makes it impossible to distinguish which "darwin" is which in
  clang-darwin-darwin.
- intel-darwin passes the wrong toolset name to gcc.init-link-flags,
  (The toolset is intel, darwin is a subfeature). (fixed)

Problems on other platforms:
- rpath is broken on windows, because the argument is not
  passed through path.native, resulting in arguments like
  /C:/path/to/lib

Issues with the new design:
- Moving away from toolset.flags to rules called from
  action.execute is a poor choice as it creates yet
  another alternative way of doing things that provides
  no real advantages.  It's less idiomatic and also
  slower than using flags.  It makes it harder to track
  down why a specific option is being applied.  It
  does not allow for any kind of introspection (i.e.
  it makes automatic feature relevance an impossible task).
  It does not allow selective overriding in derived toolsets.

Random issues that probably existed previously:
- clang-darwin duplicates options from gcc and does not
  block all the gcc options that it duplicates.
- clang-darwin doesn't seem to support strip=on
- intel-darwin doesn't permit ar and ranlib to be specified.
- intel-darwin with <runtime-link>static passes -static twice
  (once inherited from gcc).
- intel-darwin's setting of -m32/64 seems somewhat confused,
  since it's based on <instruction-set>/<address-model>,
  but gcc already adds this based on <architecture>/<address-model>.
- clang-linux duplicates a number of options from gcc, and
  passes some options twice.
- clang-linux uses -R instead or -rpath (The ld man page indicates
  that -R is accepted for compatibility)  gcc sets RPATH_OPTION
  for this.

In Christ,
Steven Watanabe