.so file following ports versioning but in the install stage tries to install
the original version. failed 4 times out of the last 13 bulk builds and it
takes an hour to build in each.
if a port needs 2.x then set MODPY_VERSION=${MODPY_DEFAULT_VERSION_2}.
This commit doesn't change any versions currently used; it may be that
some ports have MODPY_DEFAULT_VERSION_2 but don't require it, those
should be cleaned up in the course of updating ports where possible.
Python module ports providing py3-* packages should still use
FLAVOR=python3 so that we don't have a mixture of dependencies some
using ${MODPY_FLAVOR} and others not.
Some notable changes to the package with this release:
- move from Qt4 to Qt5
- move from Python 2 to Python 3
- drop dependency on py-gtk2
ok (and testing and much prodding from) rsadowski@
CMake will fail to properly run check_c_compiler_flag() on ARM when
checking for -msse2; it will always pass, and subsequent builds will
fail. Trying to compile actual code during CMake is a more reliable way
to see if SSE2 is actually available.
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.
GNU Radio is a software development toolkit that provides signal processing
blocks to implement software radios. It can be used with readily-available
low-cost external RF hardware to create software-defined radios, or without
hardware in a simulation-like environment. It is widely used in hobbyist,
academic and commercial environments to support both wireless communications
research and real-world radio systems.
GNU Radio has filters, channel codes, synchronisation elements, equalizers,
demodulators, vocoders, decoders, and many other elements (in the GNU Radio
jargon, we call these elements blocks) which are typically found in radio
systems. More importantly, it includes a method of connecting these blocks
and then manages how data is passed from one block to another. Extending GNU
Radio is also quite easy; if you find a specific block that is missing, you
can quickly create and add it.
GNU Radio applications are primarily written using the Python programming
language, while the supplied, performance-critical signal processing path is
implemented in C++ using processor floating point extensions, where
available.
ok sthen@
