The fix changes behavior in same cases, but those cases were all either
broken or showed unexpected behavior. The new behavior is very simple:
- If an argument starts with `--<option-name>=`, return whatever comes
after the equals sign.
Prior to this change, `ARGV.value` showed some unexpected behavior:
- `ARGV.value("foo")` returned `nil` for `--foo=` because at least one
character needed to be present after the equals sign. (All other
option parser implementations I'm aware of allow for empty values.)
- `ARGV.value("bar")` returned `"baz"` for `--foo=--bar=baz` because the
regular expression was not anchored to the start of the argument.
- `ARGV.value("++")` raised an exception because the string wasn't
escaped for use in the regular expression. (An unlikely corner case.)
Closes#231.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
When passing formula options with value, e.g. `--with-qt=5`, to the
child process responsible for building a formula, `ARGV.value` would be
invoked with `nil`. Handle this more elegantly (no change in behavior).
For consistency, use a regular expression adapted from `Options.create`
instead of the somewhat bogus one used before.
I'm not completely sure this is "sane" logic but I'm leery of just reverting
Andrew's work this morning and making him rebuild that PR from scratch for one
syntax issue.
Sadly, because we run:
```
brew readall --aliases --syntax
```
On every CI job, and that flags this line previously as:
```
pull.rb:555: warning: possibly useless use of a variable in void context
```
Every single PR has "failed" since it was merged, and it's reached the point
of being a bit annoying, so let's try this.
Fix regression introduced in fafe8f0f53bf91fc41f016b5c2af41ca712783f7.
Counting the number of hyphens in a string cannot be done in a single
expression, thus split this and introduce another local variable.
Fixes#227.
The previous fixes in c6dc50fcf05c8c4956ac86345360fefcb00f664e and
ed9f7308b265944c27c833b9a2aaa0e911ff5667 were incomplete as they
referenced `DeveloperTools`, but the actual name is `DevelopmentTools`.
Also fixes indentation and a broken `MacOS.clang_version` (it was
falsely redirecting to `DeveloperTools.llvm_build_version` ).
References #219.
References #220.
If the environment variable HOMEBREW_TEST_GENERIC_OS is set ensure that
neither Mac nor Linux-specific code is loaded. This allows easier
testing of cross-platform code on OS X and will make it easier to port
Homebrew to platforms other than OS X and Linux.
This is in part designed to handle situations described in https://github.com/Homebrew/legacy-homebrew/issues/42273
where we tell someone to install a special dependency, but because we (rightly, IMO)
resolve special dependencies first users can end up being told to execute a command
on a tool that isn't yet installed and isn't immediately obvious how to install it.
In the situation raised there, with the `sile` formula people are being told to
`luarocks install xyz` but we hadn't installed Lua for them first, so they just
get a `command not found: luarocks` message. Perhaps it should be obvious enough
how to install said tools by looking at the formula's dependencies,
but it's not a huge burden on us to make life easier than that.
Shuffled over from https://github.com/Homebrew/legacy-homebrew/pull/42576.
- Reorder listed commands to better reflect a typical workflow (search,
then query for details via `info` and friends, then install, later
update and upgrade, at last maybe uninstall).
- Remove niche `pin` and `unpin` commands.
- Drop `--env` in the Troubleshooting section.
And use `/REGEX/` instead of `/PATTERN/` to be clearer what is expected.
Closes#177.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
