Copy the cmake directory in the InstallDev step.
I am currently trying out actual host build for boost i.e. compiling
boost libaries for host tools. When I do that, that step installs the
boost cmake files in staging_dir/host.
This breaks other packages that use cmake to compile and use boost as a
dependency. This is because, their compilation step now begins using
staging_dir/host version of Boost, rather than the target version of
boost. Cmake gives priority to cmake version of Boost config, over
finding boost headers manually.
This change resolves that problem by installing the BoostConfig.cmake
file in staging_dir/<target> as well.
Compile tested: nbg6817
Signed-off-by: Amol Bhave <ambhave@fb.com>
Boost 1.70.0 broke the apply_visitor functions for lvalue reference
variants.
This imports the patch that fixes this issue from upstream.
Tested this by compiling a library
(https://github.com/facebookincubator/fizz) that works with 1.69 but
breaks with 1.70. And then, importing this patch and trying the
compilation again.
Compile tested: nbg6817
Maintainer: @ClaymorePT
Signed-off-by: Amol Bhave <ambhave@fb.com>
sigar is a System Information Gatherer And Reporter library for C++
Adding the package so other C++ packages that depends on this library
can build.
This creates a libsigar.so shared library.
Signed-off-by: Amol Bhave <ambhave@fb.com>
- update to 1.0.77
- apply patches from Rosen Penev for compatibility with uClibc-ng
- add an option for rotation_rate selection
Signed-off-by: Maxim Storchak <m.storchak@gmail.com>
* Update (lib)x264 to 20190324
* Stop using GNU Autotools and use libx264's own
configuration facility
* Drop hardcoded CFLAGS, x264 will handle those fine on its own
This will override toolchain optimizaion and set -O3
irregardless of setting.
* Rework LTO and ASM optmization selection to make it more
compact and readable. This drops optimization for x86 32-bit
which is being deprecated in favour of x86_64 in general and
the very few systems still in use that doesn't support 64-bit
are too slow to be usable anyway.
* Import patches to fix compilation on ARM and x86 (32-bit)
from OpenEmbedded
* Minor style fixes to Makefile
Source: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-multimedia/x264/x264
Signed-off-by: Daniel Engberg <daniel.engberg.lists@pyret.net>
It seems ever since the switch to uClibc-ng, this builds perfectly fine.
Moved PKG_MAINTAINER variable for consistency between packages.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
OpenWrt uses uClibc-ng now, and it seems that these are no longer needed
as it seems faad2 automatically renames these functions.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Upstream makes infrequent releases while having an active git repository
with important bugfixes.
Removed maintainer from all three packages due to inactivity.
Removed systemd support as systemd is not used in OpenWrt.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Upstream has really infrequent releases while having an active git
repository with important bugfixes. This is also needed because
libimobiledevice requires a new API from libusbmuxd.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Upstream makes seriously infrequent updates whereas they have an active
git repository with important bugfixes.
Also fixed compilation without deprecated OpenSSL APIs.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Since no Python packages are produced by this package, including
python-package.mk is unnecessary.
This removes the reference to python-package.mk. (PKG_RELEASE is
unchanged as this should have no effect on the build.)
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
The note was note correct when mentioning encodings vs python[3]-codecs.
This change fixes this confusion.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Since no Python packages are produced by this package, including
python-package.mk is unnecessary.
This removes the reference to python-package.mk. (PKG_RELEASE is
unchanged as this should have no effect on the build.)
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This describes the proposal outlined in #8520, with a few
additions/modifications:
* Describes the handling of the Python 2 interpreter
* Allows for normal updates of Python 2 libraries that share the same
Makefile as their Python 3 version
* Mass removal event has a name
Supersedes #8788.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>