GitLab

_CC is set to the default compiler, which might be g++ instead
of gcc for C++ projects.

Makes it easier to set optional parameters, such as the
universal archs

Static library frameworks can be generated with both a fat and a thin
binary, depends on the arch selected for the build.

In case it is a fat library, extra work is required to split the fat
small libraries into its thin parts, merge their objects together separately
and then create a new fat library from the merged thing versions

Refactor to a module function to allow it to be used from both
the ios and osx packagers

only try to copy the main framework library if it has already been
created

ios packages are shipped as a Framework directory into a .dmg file.

The framework contains a static lib that is the result of merging all
static libs required for the intended package

Split the apple's framework creation class into 2 subclasses for creating
dynamic and static frameworks.

The dynamic one is used of OSX packaging, the static should be used for
iOS

This ensure that we end up with an ARMv7 statix library instead
of an ARM one when building for the Architecture.ARMv7 target

Thiago Santos authored Mar 04, 2013 and Andoni Morales Alastruey committed Mar 07, 2013

Use the same gliconfig.h hack for ios to allow universal builds
to properly include it

makes it easier to spot which recipe fails when testing builds

Some recipes just copy files around and are performed very fast. This
confuses the new files listing for universal builds as it relies on
the timestamps of the new files to select what are the new ones.

When the build is faster than the FS timestamp resolution, old files and
new files can be mixed together, causing old files to be removed from the
final prefix destination dir. A case of this is when gst-sdk-shell is built.

This patch prevents this by waiting a little before attempting to install files to
the prefix, so that the new files have a timestamp difference to the old ones

It is a requirement to build taglib recipe

In newer osx versions, the packagemaker might be installed manually
as it doesn't seem to come bundled with XCode anymore.

In this case, the usual location is for it to be installed at
the Applications directory. This patch makes the packager search
for it in the old directory and in Applications