dependent ports, this restricts deps to use the current clang version
which is required for some ports using the unversioned libLLVM*.so
library. see https://marc.info/?l=openbsd-ports&m=152377935312657&w=2
- set RUN_DEPENDS on devel/llvm in lang/crystal as it uses libLLVM*.so
breakage reported by James Turner
I don't like this at all, but don't see what other option we have,
if anyone has a better idea please pipe up.
gdb is picked up because it brings libbfd, which can be used by
ocamlobjinfo to analyze (at least) .cmxs files. Not very useful on
arm64 since native code support isn't enabled, but this is consistent
with other similar architectures.
An alternative would be to drop BFD on non-native non-dynlink archs, if
it is actually used only for .cmxs files.
Late commit because I wanted to avoid conflicting with the ongoing OCaml
update, but this one will need a refreshed diff anyway.
Tested by kettenis@
Crystal is a programming language with the following goals:
* Have a syntax similar to Ruby (but compatibility with it is not a
goal)
* Be statically type-checked, but without having to specify the type
of variables or method arguments.
* Be able to call C code by writing bindings to it in Crystal.
* Have compile-time evaluation and generation of code, to avoid
boilerplate code.
* Compile to efficient native code.
Initial port and MAINTAINER Wesley Moxam
Help and ok sthen@
Bumping REVISION for libpgmath and flang (but not driver). Mostly because
of a PLIST sync, but also because the build did change: includes a patch to
stop clang from silently passing off some of the build work to base gcc
(which obviously failed on arm64).
- add patch to work around boostrap execpath stuff (api not exposed yet)
- regen patches
- remove upstreamed patches
- remove orig entries in plist (thanks espie@)
No objections.
This fixes the /var/www/conf/modules.sample.php-${PV}.conf (which
was just a copy of the apache module itself).
Bump -main and -apache.
Adjust @conflict markers (reminded by sthen@).
ok sthen@
share/php-${PV}/include/ext/pcre/php_pcre.h pulls in pcre.h which is
no longer installed by PHP and the include path isn't setup to find it
from devel/pcre. Reported by aja@ with pecl-imagick,php70.
in the foo|bar|baz list. rpe@ noticed that this wasn't picking the
wanted default in cases where the PKGNAME match wasn't exact;
explanation about how the matching is done from espie@
produced packages are named according to PKGNAME-main/PKGNAME-wx) but
means that the port work directory has 'erlang' in the name rather
than 'otp', making it easier to identify the responsible port when
searching a big tree of source unpacked with "make extract".
- pick some <space><tab> nits while there
