lbrycrd/depends
Cory Fields bb44d9e754 depends: fix a static qt5 crash when using certain versions of libxcb
See here for background: https://bugreports.qt.io/browse/QTBUG-34748

libxcb temporarily had an abi breakage which caused crashes when qt was
compiled against a non-compatible version. Building qt with -qt-xcb should have
shielded us from this issue, except that incompatible headers were used when
building qt's wrapper.

Make sure those headers aren't picked up by qt's build.

Details:

qt's build adds a wrapper around the xcb libs when -qt-xcb is used. This is
done to avoid having to link to a handful of different libs, which may not be
api/abi stable. This build depends on include-order, so that its files are
found before the real libxcb headers.

Our build (for other reasons related to qt's complicated build-system) injects
our prefix into CXXFLAGS. Because libxcb is found in this path, that reverses
the include-order, negating the purpose of the wrapper.

To fix, libxcb's includes are simply moved to a subdir. pkg-config ensures that
they're still found properly when needed.

To make things even more interesting, this behavior in qt's .pro files is broken:
INCLUDEPATH += $$QMAKE_CFLAGS_XCB

The INCLUDEPATH variable is processed by qmake which automatically prefixes each
entry with "-I". The QMAKE_CFLAGS_XCB variable comes from pkg-config and
already contains -I, making the path look like "-I-I/path/to/xcb/headers".

To work around that, CFLAGS/CXXFLAGS are used here rather than INCLUDEPATH.
2015-03-16 23:45:15 -04:00
..
builders depends: add sensible download timeout/retry values 2014-08-27 03:40:30 -04:00
hosts osx: bump build sdk to 10.9 2015-01-20 01:49:20 -05:00
packages depends: fix a static qt5 crash when using certain versions of libxcb 2015-03-16 23:45:15 -04:00
patches depends: fix a static qt5 crash when using certain versions of libxcb 2015-03-16 23:45:15 -04:00
.gitignore depends: add shared dependency builder 2014-08-08 15:10:46 -04:00
config.guess depends: latest config.guess and config.sub 2015-01-21 15:48:27 +08:00
config.site.in depends: quit exporting in config.site 2014-11-18 18:06:47 +01:00
config.sub depends: latest config.guess and config.sub 2015-01-21 15:48:27 +08:00
funcs.mk depends: fix typos 2015-01-31 17:38:28 -05:00
Makefile depends: always use static qt5 for linux 2015-02-25 18:41:59 -05:00
README depends: fix typos 2015-01-31 17:38:28 -05:00
README.packages depends: add docs for debug 2014-09-25 14:56:26 -04:00
README.usage depends: always use static qt5 for linux 2015-02-25 18:41:59 -05:00

This is a system of building and caching dependencies necessary for building
Bitcoin.

There are several features that make it different from most similar systems:

- It is designed to be builder and host agnostic

In theory, binaries for any target OS/architecture can be created, from a
builder running any OS/architecture. In practice, build-side tools must be
specified when the defaults don't fit, and packages must be amended to work
on new hosts. For now, a build architecture of x86_64 is assumed, either on
Linux or OSX.

- No reliance on timestamps

File presence is used to determine what needs to be built. This makes the
results distributable and easily digestable by automated builders.

- Each build only has its specified dependencies available at build-time.

For each build, the sysroot is wiped and the (recursive) dependencies are
installed. This makes each build deterministic, since there will never be any
unknown files available to cause side-effects.

- Each package is cached and only rebuilt as needed.

Before building, a unique build-id is generated for each package. This id
consists of a hash of all files used to build the package (Makefiles, packages,
etc), and as well as a hash of the same data for each recursive dependency. If
any portion of a package's build recipe changes, it will be rebuilt as well as
any other package that depends on it. If any of the main makefiles (Makefile, 
funcs.mk, etc) are changed, all packages will be rebuilt. After building, the
results are cached into a tarball that can be re-used and distributed.

- Package build results are (relatively) deterministic.

Each package is configured and patched so that it will yield the same
build-results with each consequent build, within a reasonable set of
constraints. Some things like timestamp insertion are unavoidable, and are
beyond the scope of this system. Additionally, the toolchain itself must be
capable of deterministic results. When revisions are properly bumped, a cached
build should represent an exact single payload.

- Sources are fetched and verified automatically

Each package must define its source location and checksum. The build will fail
if the fetched source does not match. Sources may be pre-seeded and/or cached
as desired.

- Self-cleaning

Build and staging dirs are wiped after use, and any previous version of a
cached result is removed following a successful build. Automated builders
should be able to build each revision and store the results with no further
intervention.