defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
Simplify some ports where DragonFlyBSD no longer needs to be special-cased.
Submitted by: rene
Reviewed by: bapt, jbeich
Differential Revision: https://reviews.freebsd.org/D17724
Change x11/xorgproto to become a build time dependency when added to
USE_XORG. Change the dependency to be on the port, rather than a file the
port installs.
Fix fallout.
Bump portrevision on depending ports.
PR: 230909
Reviewed by: eadler
Approved by: portmgr (antoine)
Obtained from: https://github.com/FreeBSDDesktop/freebsd-ports/tree/feature/xorgproto
exp-run: antoine
Differential Revision: https://reviews.freebsd.org/D16906
Ports using USE_PYTHON=distutils are now flavored. They will
automatically get flavors (py27, py34, py35, py36) depending on what
versions they support.
There is also a USE_PYTHON=flavors for ports that do not use distutils
but need FLAVORS to be set. A USE_PYTHON=noflavors can be set if
using distutils but flavors are not wanted.
A new USE_PYTHON=optsuffix that will add PYTHON_PKGNAMESUFFIX has been
added to cope with Python ports that did not have the Python
PKGNAMEPREFIX but are flavored.
USES=python now also exports a PY_FLAVOR variable that contains the
current python flavor. It can be used in dependency lines when the
port itself is not python flavored. For example, deskutils/calibre.
By default, all the flavors are generated. To only generate flavors
for the versions in PYTHON2_DEFAULT and PYTHON3_DEFAULT, define
BUILD_DEFAULT_PYTHON_FLAVORS in your make.conf.
In all the ports with Python dependencies, the *_DEPENDS entries MUST
end with the flavor so that the framework knows which to build/use.
This is done by appending '@${PY_FLAVOR}' after the origin (or
@${FLAVOR} if in a Python module with Python flavors, as the content
will be the same). For example:
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR}
PR: 223071
Reviewed by: portmgr, python
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D12464
If you want to set WRKSRC, set GH_PROJECT instead.
- The GitHub URLs are case insensitive, but the distribution files you
get out of them are not.
- If the repository was renamed, the old URL will still work, but the
distribution name will be ith the new name.
Sponsored by: Absolight
- Mark broken: fails to build
hal/user_comps/mb2hal/mb2hal.c:362:63: error: too few arguments to function call, expected 3, have 2
modbus_set_response_timeout(this_mb_link->modbus, &timeout);
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
/usr/local/include/modbus/modbus.h:185:12: note: 'modbus_set_response_timeout' declared here
MODBUS_API int modbus_set_response_timeout(modbus_t *ctx, uint32_t to_sec, uint32_t to_usec);
^
hal/user_comps/mb2hal/mb2hal.c:369:59: error: too few arguments to function call, expected 3, have 2
modbus_set_byte_timeout(this_mb_link->modbus, &timeout);
~~~~~~~~~~~~~~~~~~~~~~~ ^
/usr/local/include/modbus/modbus.h:188:12: note: 'modbus_set_byte_timeout' declared here
MODBUS_API int modbus_set_byte_timeout(modbus_t *ctx, uint32_t to_sec, uint32_t to_usec);
^
lathes, 3d printers, laser cutters, plasma cutters, robot arms,
hexapods, and more.
- Accepts G-code input, drives CNC machines in response.
- Active user community.
- Several different GUIs available.
- Compatible with many popular machine control hardware interfaces.
- Supports rigid tapping, cutter compensation, and many other advanced
control features.
WARNING: This port is simulation-only for now.
WWW: http://linuxcnc.org/
