On 2019/04/15 00:54, Charlene Wendling wrote:
>
> Erlang (all versions) doesn't package with ports-gcc-8, because:
>
> - WxWidgets is built with headers made for ports-gcc-8, with
> C++14 as the standard C++ version.
>
> - Erlang requires WxWidgets but uses base-gcc, and during
> configuration, it indeed outputs in $WRKSRC/lib/wx/config.log:
>
> "/usr/local/include/wx-3.0/wx/strvararg.h:25:27: error:"
> "type_traits: No such file or directory"
>
> AFAIK base-gcc wants <tr1/type_traits>
>
> - Meanwhile, it just builds without Wx, the issue appears when
> packaging, because the Wx related files are not present.
>
>
> It should have been easy if CHOSEN_COMPILER wasn't "irrelevant",
> and if we were able to define it, but it would break the build on
> clang archs.
>
> What i'm proposing here is to bypass CHOSEN_COMPILER for !clang
> arches. It unbreaks the packaging and ensures that WANTLIB is
> proper, calling egcc/++ directly seems a bit too rough though.
>
> It has been tested against Erlang 16 and 18, as my partial bulk
> is still ongoing, i don't have resources to try them all.
This mess is due to a conflict between the variable name COMPILER in
infrastructure, and the mechanism used in the Erlang ports Makefile
to substitute e.g. "compiler-7.3" with "${COMPILER}" in the plists.
It isn't passed to the erlang build, it's just done for the port.
The "COMPILER=irrelevant" thing in Makefile.inc was done as a quick
fix in the gcc/clang transition but it's confusing and gets in the way.
And with wxWidgets we *do* want to use COMPILER the way it was intended.
Rather than stacking another hack on top of the existing
"CHOSEN_COMPILER=irrelevant" one, let's just get rid of it.
There are two approaches -
- either we can just get rid of the mechanism completely (it isn't
used consistently; compare 19/pkg/PLIST-main with the others). Upside:
simple. Downside: bigger PLIST diffs between Erlang updates.
- or we can rename the variables used (prefix with E_ or something),
either just COMPILER to reduce PLIST churn, or all of them.
I'm leaning towards the first one. Builds ongoing ...
