This is used with fails_with_llvm so that if GCC cannot be found (and we suspect this is the case with Xcode 4.2) the build will fail.
Quite possibly it should be the default.
Look in /usr/bin because all versions of Xcode install it to /usr/bin now and this allows us to support Xcode-less installs of Apple's developer tools.
I inadvertently gzipped it last night. That in itself doesn't cause any
tests to fail because the download strategy code is robust, but it's
fixed here anyway to be consistent. Basically, I'm dumb.
I also took the opportunity to remove the other resource fork file, so
the tarball is clean.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
FixesHomebrew/homebrew#7329.
FixesHomebrew/homebrew#7269.
FixesHomebrew/homebrew#7236.
Also quite a lot of tidy. This should all work fine.
I think we only started referring into xcode_prefix because LLVM used to not
be linked into /usr/bin. But for sure this is no longer true. If someone out
there doesn't link cc etc. into /usr/bin then I guess we can revise this patch
but it's not something we officially supported before, it was just an
accident.
I added a test step in the init code so that a working compiler will always be
selected. This is mainly a fallback for old Xcodes. Though a comment in
another area of the code suggested Xcode 3 on 10.5 doesn't have LLVM so…
The test_a_basic_install was failing because it expected
libexec.children.length to be 1, when in fact there were two files in
the untarred libexec: NOOP, and the Mac OS X resource fork file ._NOOP.
That file is now removed, and the test passes.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
`brew fetch --force` was a no-op for formula pathnames when that formula
did not exist in Library/Formula, because `brew --cache #{f.name}`
results in an error for that case.
Fix it by always using f.cached_download.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
`svn up` doesn't take url argument; compare `svn help up` to `svn help checkout`
Apparently `svn up` can ignore this argument (not documented), but providing this
argument could confuse code readers into believing that changing the url will
switch the branch. It doesn't; the argument is ignored.
This fix was relayed to me, but I've studied it further before posting.
It is related to the bug where --HEAD installs reuse the wrong cache.
Reading the former code, one might hope that providing a changed URL would
have `svn up` change branches. It doesn't; the url was ignored.
ClosesHomebrew/homebrew#7159.
Signed-off-by: Max Howell <max@methylblue.com>
`brew update` was treating all changes to internal commands as
deletions due to a typo, resulting in spurious notifications of removed
commands.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
Specify the refspec 'refs/heads/master:refs/remotes/origin/master' so
that the remote-tracking branch origin/master gets update during `brew
update` (git-pull updates remote-tracking branches when invoked
like `git pull` or `git pull origin`, but not `git pull origin master`).
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
Rationale: brew doctor shouldn't give warnings for a default install. And this particular warning only applies for a small subset of formula: the ones that are "dupes".
If we get reported issues that prove this was a mistake we will revert it.
It seems like latest build of Xcode 4.2 doesn't create "-4.2" links in /usr/bin. Because of this recipes fail with "configure: error: C compiler cannot create executables" error.
ClosesHomebrew/homebrew#7254.
ClosesHomebrew/homebrew#7276.
Signed-off-by: Max Howell <max@methylblue.com>
Amended to work as intended, since /usr/bin/cc is actually since Xcode 4.
Amended commit message. First line must be less than 72 characters! :P
Executing `curl(*patches)` was failing on Leopard when `patches` was an empty
list. `git-bisect` identified 48552bb42a69ece4eb2a6d9acf81a0b47adb19c9 as the
commit that caused this bug to surface by adding `--insecure` to the arg list
on Leopard. This is odd because the following both exit with status 2:
curl
curl --insecure
The only apparent difference is that `curl --insecure` prints "no URL
specified!" to stderr along with the usage message.
Also renamed `patches` to `external_patches` as it is more descriptive.
