This can just use the default `tar` invocation, which successfully
recognizes the type automatically. In fact, `.tar.gz` and `.tgz` are
already listed by that particular case anyways.
The entirety of `.port_include.sh` depends on having a current working
directory for the respective port. If we were to remove the directory,
some actions such as `fetch` could fail since our current working
directory would now be an invalid inode.
This issue was exposed by running `./package.sh` followed by
`./package.sh dev` and answering 'y' to the question on cleaning the
build directory.
While at it, pass the `--3way` option to give the user something to work
with. Otherwise, Git will just prepare the commit metadata and nothing
else. Note that this has a relatively low chance of working, since the
recorded blob hashes aren't known to a freshly imported repository.
The ports `libvorbis`, `readline` and `timidity` would not install on
macOS as a result of using `sed -i` without an extension provided. GNU
sed is available through Homebrew, but it does not replace `sed` by
default.
Instead, provide a new `sed_in_place` function that calls `sed` with the
right arguments.
Sets `$LD` to `$HOST_LD` in `.port_include.sh` if it is defined as well,
else it will be set to `ld`.
Makes libiconv build with the Clang toolchain.
This also impacts other ports when building them with the Clang
toolchain, and might result in more ports building correctly.
When using cmake --build, CMake will look for this environment variable
to enable parallelism. The Zig port, for example, uses cmake --build,
and will otherwise use a single core if cmake selects Make as the build
system. This should help with all ports which use cmake --build.
When building a port with `useconfigure="false"`, the `do_configure`
function invokes a `buildstep` with multiple positional arguments as the
command to execute.
It then tests whether the positional arguments evaluate to an emtpy
string, but could fail when multiple positional arguments were provided.
This resulted in the following warning when building the Composer port,
for example:
../.port_include.sh: line 16: [: echo: binary operator expected
Prevent this warning by testing against the number of positional
arguments, instead.
previously every buildstep would return a success error code. As a
result, all the steps would run even if previous steps failed.
I've also added a red status message when this happens.
We were previously comparing the hash against the hash after the initial
import, which caused us to regenerate patches every time as long as we
did have patches (even if they haven't changed at all) and the script
entirely missing that it should remove patches if the current commit is
the "import" commit.
I've lost more changes to "you forgot to push the changed commits to the
remote" than I'd like to admit, so let's just unify both and only ever
use the actual working repository for detemining whether any patches
have changed.
This stops us from mangling our LLVM patch names and titles when using
`./package.sh dev`, as they like to put their category names in square
brackets.
There were only two packages making use of this functionality, but it
seems more sensible to have a fixed implementation for the cleaning of
ports - especially now they delete the entire build directory and/or
dist files.
The functionality for `./package.sh clean` was a bit weird: based on
whether you were working in dev mode, it would try to delete either
`$workdir` or `$nongit_workdir` and `*.out` from your `pwd`.
The new functionality is pretty clear: `./package.sh clean` deletes the
entire build directory for the port regardless of what mode you're in,
`./package.sh clean_dist` removes all `$files`, and
`./package.sh clean_all` does both.
This lets us eliminate the extra arguments on CC and CXX for ports that
care about CC and CXX pointing to actual filenames they can invoke
realpath or basename on.
While `core.autocrlf=false` should be the default, there will certainly
be users that have changed the default setting in their global
configuration.
Ensure that the setting is disabled to avoid accidentally mangling or
not applying our patches.
Some ports may have more than one `config.sub` that is in use (vendored
dependencies, etc.). Instead of fiddling about with space-delimited
strings, let's just make that setting into an array right away.
This keeps users from leaking their host environment variables (CFLAGS,
etc.) into Ports, and it keeps us from leaking Port-specific settings
into their dependencies.
