I tried to follow the instructions outlined in PACKAGING THE SDK,
and as it turns out the instructions for Linux required more than
40GB of disk space. That's why I think it would be best to tell
readers that they might need up to 45GB of space rather than
up to 25GB. I'm not sure if the instructions are simply outdated
in this regard or if the space requirements are just different for
other reasons, however I highly suspect the former to be the case.
This change updates the exit code for `verify_sdk_version` to `1` function if the SDK is not found.
This should help to stop the build in automatic scripts when the SDK_VERSION env variable is set to a invalid value.
As OpenSSL is expected to be in a standard UNIX location but that's not always the case on macOS, this works around the issue regardless of package manager used as long as pkg-config is installed into $PATH
Macports default prefix is /opt/local
Homebrew on M1 uses /opt/homebrew
Move setting build_complete_file to after fetching project_name using
get_project_name_from_url. Avoids empty ".FOO_build_complete" file name.
* Fix up a number of shellcheck issues in get_sources().
Signed-off-by: Ben Kochie <superq@gmail.com>
Being able to extract SDKs from Command Line Tools for Xcode instead
of the full Xcode package saves bandwidth, disk space, and time.
Two scripts are added:
* tools/gen_sdk_package_tools.sh: extracts SDKs from installed
Command Line Tools on macOS (/Library/Developer/CommandLineTools)
or from a path specified via XCODE_TOOLS_DIR
* tools/gen_sdk_package_tools_dmg.sh: unpacks the content of provided
Command_Line_Tools_for_Xcode.dmg and extracts SDKs via the above
script.
Tested with Command Line Tools for Xcode 12.x.
To get a completely env independent setup we may want to install
Clang/LLVM to the target folder as well. So let's allow user
to do it in a scripted way just adding ENABLE_CLANG_INSTALL=1
for execution string.
There're quite a few mirrors where GNU software might be found.
Though there're some problems with them:
1. There's no guarantee any random mirror will be still up tomorrow
2. For mere mortal it's not clear how credible if xxx-yyy-zzz.org
in a sense that either tarball with sources might be corrupted
unintentionally or even with some bad intentions.
One solution here might be calculation of checksum but still
as long as the main "FTP" storage of GNU project is up there's
not much sense in using a _hard-coded_ mirror.
Unfortunately snapshots of GCC are not hosted at https://ftp.gnu.org/,
so keeping https://mirror.koddos.net for now.
