some existing COMPILER lines with arch restrictions etc. In the usual
case this is now using "COMPILER = base-clang ports-gcc base-gcc" on
ports with c++ libraries in WANTLIB.
This is basically intended to be a noop on architectures using clang
as the system compiler, but help with other architectures where we
currently have many ports knocked out due to building with an unsuitable
compiler -
- some ports require c++11/newer so the GCC version in base that is used
on these archirtectures is too old.
- some ports have conflicts where an executable is built with one compiler
(e.g. gcc from base) but a library dependency is built with a different
one (e.g. gcc from ports), resulted in mixing incompatible libraries in the
same address space.
devel/gmp is intentionally skipped as it's on the path to building gcc -
the c++ library there is unused in ports (and not built by default upstream)
so intending to disable building gmpcxx in a future commit.
Of course this is an ugly kludge, so someone (tm) should dig into our
libtool internals and figure out why -lpng disappears from the
commandline when linking xetex on !x86.
somehow, between builds starting 2018-05-13 and 2018-07-31 building xetex
started failing because the libtool-generated linker command stopped including
-lpng (https://marc.info/?l=openbsd-ports&m=153911844712950&w=2).
unsure of the reason and it's not a satisfying fix, but does at least get
TeX packaging on sparc64 for 6.4.
ok naddy@
Although this is a "no functional change" commit, the change does two
things:
* Removes the dependency on py-texscythe for generating the PLISTs.
Instead, I've added a small TLPDB parser which works (unlike
py-texsythe) entirely in-memory. This means that generating the
PLISTs now takes seconds instead of minutes.
* Splits the generation of the PLISTs into two scripts. The first --
update_plist_hints.py -- emits one line for file under the fake
install dir, advising which PLIST the file should go in. The second
-- write_plists.py -- reads those lines and writes them to the
correct PLIST. Eventually write_plists.py will be killed, as we plan
to integrate update_plist_hints.py with update-plist(1) itself.
At a later date, I will port all of these scripts to Python3, since that
seems to be the way the world is going.
The idea to integrate with update-plist(1) is espie@'s, and this change
is also OK espie@.
Many thanks.
