osxfuse 2.6.1

[bfleischer]

Add FUSE for OS X formula

[mistydemeo]

Homebrew needs to be able to dictate compiler choice.

[bfleischer]

osxfuse will not work with all compilers. Especially on Mac OS X 10.6 there are known issues resulting from using llvm or clang. The osxfuse build script picks a working compiler depending on the version of Xcode that is installed.

[mistydemeo]

I'd prefer that the compilers get marked in our fails_with notation so it's clear to us what it does/doesn't work with. That will govern compiler selection based on what's available.

[bfleischer]

Another problem I ran into before putting ENV.remove_cc_etc in was that homebrew seems to override some Xcode build settings resulting in the osxfuse build to fail. I'd prefer not rewriting the whole build process.

[mistydemeo]

That method unsets the following environment variables:

CC CXX OBJC OBJCXX LD CPP CFLAGS CXXFLAGS OBJCFLAGS OBJCXXFLAGS LDFLAGS CPPFLAGS

If you can figure out what breaks it you can unset those environment variables, but we would prefer to track what compiler is being used.

[mistydemeo]

You can do this simply as depends_on :macos => :snow_leopard in the dependencies.

[bfleischer]

Thanks. I was looking for something like this but didn't find it in the cookbook.

[mistydemeo]

It's recent; still needs to get added.

[mistydemeo]

No need to create a variable and then return it; Ruby automatically returns the last value in the method, so just do

def caveats; <<-EOS.undent
  ...
  EOS
end

[mistydemeo]

Don't need a newline here.

[mistydemeo]

Don't need the extra newline, the caveats will already end with one.

[mistydemeo]

(I see the caveats were borrowed from fuse4x directly so apologies for the pedantry.)

[samueljohn]

for autoconf and automake, please use
depends_on :autoconf and depends_on :automake the => :build time dep is implicit there.

[bfleischer]

The => :build seems to be necessary to make @BrewTestBot happy. Without this I'm getting

Error: 4 problems in 1 formulae
osxfuse:

• stable version 2.6.1 is redundant with version scanned from URL
• autoconf dependency should be "depends_on 'autoconf' => :build"
• automake dependency should be "depends_on 'automake' => :build"
• Don't need to interpolate "prefix" with system

[jacknagel]

You need to use the symbol style (:autoconf)

[bfleischer]

@jacknagel Thanks

[samueljohn]

gettext is only a build time dep? Just asking. I dunno. No dynamic linking I assume, eh?

[bfleischer]

It's only needed for its config.rpath file.

[samueljohn]

please indent by 2 spaces (I do this myself often as I come from python).

[samueljohn]

Ah now I see, because the EOS is dedented.
Perhaps Just move <<-EOS.undent below the def caveats and indent by 2 spaces?

[samueljohn]

Cool, I am very exited by this, so we can finally have osxfuse and perhaps later even TrueCrypt! No more warnings about unbrewed dylibs in my /usr/local.

[bfleischer]

There is still the "ENV.remove_cc_etc" issue.

Is there a way of telling homebrew which compiler to use when building osxfuse? The fails_with construct will not work for me because this would require a lot of additional testing on every osxfuse release. I simply don't have the time to run a complete series of tests on every version of Mac OS X using every compiler available. This would take several days.

I don't think it would be responsible regarding the users not testing osxfuse extensively. In the worst case scenario the wrong compiler will result in kernel panics and probably cause data loss.

[manphiz]

IMHO @BrewTestBot will help testing. The build log shows what problems need to solve.

[bfleischer]

@manphiz osxfuse will compile just fine with most (if not all) Xcode compilers. The issues I'm referring to are runtime issues. I've seen seemingly random crashes when using the osxfuse kernel extension, that was built with llvm-gcc or clang on Mac OS X 10.5 and 10.6. Those are compiler issues, that are not obvious when building osxfuse.

[bfleischer]

@BrewTestBot fails to build osxfuse (Build #923). Configurations lion and mountain_lion report:

Warning: Your compilers are different from the standard versions for your Xcode.
If you have Xcode 4.3 or newer, you should install the Command Line Tools for
Xcode from within Xcode's Download preferences.
Otherwise, you should reinstall Xcode.

This seems to be a @BrewTestBot issue, that has nothing to do with the osxfuse formula, right?

Configuration snow_leopard reports:

==> Installing osxfuse
==> Cloning https://github.com/osxfuse/osxfuse.git
git --git-dir /Library/Caches/Homebrew/osxfuse--git/.git status -s
Removing invalid .git repo from cache
git clone --depth 1 --branch osxfuse-2.6.1 https://github.com/osxfuse/osxfuse.git /Library/Caches/Homebrew/osxfuse--git
You must: brew install git
Error: Failure while executing: git clone --depth 1 --branch osxfuse-2.6.1 https://github.com/osxfuse/osxfuse.git /Library/Caches/Homebrew/osxfuse--git

Do I need to add a depends_on 'git' => :build line for Snow Leopard to address this? I've looked at some other formulas but but could not find a single one that does this.

I've tested the formula on clean installs of 10.6 (Xcode 3.2.6 with brew install git), 10.7 (Xcode 4.6.3 with CLT installed), and 10.8 (Xcode 4.6.3 with CLT installed) without any issues. I could really use some help here.

[manphiz]

Ah these testings can be time consuming. Thanks for the explanation.

On Sun, Jul 21, 2013 at 3:28 AM, Benjamin Fleischer
notifications@github.com wrote:

@manphiz osxfuse will compile just fine with most (if not all) Xcode
compilers. The issues I'm referring to are runtime issues. I've seen
seemingly random crashes when using a osxfuse kernel extension built with
llvm-gcc or clang on Mac OS X 10.5 and 10.6. Those are compiler issues, that
are not obvious when building osxfuse.

—
Reply to this email directly or view it on GitHub.

[CyberCastle]

Hi

Right now I'm using this formula with ntfs-3g (https://gist.github.com/CyberCastle/077caa74be2472bfacd3), a few problems, but overall, everything works fine.

Greetings

[bfleischer]

Are there any news regarding this pull request? Can it be merged?

[alugowski]

I'm excited for this! It will be great to have an up to date FUSE in homebrew. Hopefully the sshfs formula can be updated next :)

I'm experiencing occasional kernel panics with the current homebrew old sshfs/fuse4x combo, so this will be great.

[samueljohn]

@BrewTestBot test this please

[samueljohn]

So does this compile with clang?

[samueljohn]

If only support one compiler, I'd suggest to use clang and use fails_with to declare llvm-gcc and gcc are not working.

[mistydemeo]

My preference is also to document the compilers in the formula.

@bfleischer If you're already testing it and selecting compilers, then documenting that with fails_with in the formula shouldn't be too much extra work, right?

Other maintainers: the fuse4x formula currently ignores our compiler selection and selects on its own, the same way that osxfuse is. My preference is for homebrew to document/control the compiler selection for osxfuse though. Thoughts? cc @jacknagel, @MikeMcQuaid, @adamv

[MikeMcQuaid]

Agreed.

[bfleischer]

This formula can be built on 10.6 to 10.9 using 9 different version of Xcode (3.2, 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 5.0). All versions come with at least two compilers, some with three. This comes down to more than 20 different compiler versions. homebrew currently includes a formula for llvm. Would it be possible for homebrew to select a compiler, that does not ship with Xcode, for building osxfuse?

As it is it takes me roughly two days to test each osxfuse release on all supported versions of Mac OS X (and architectures). Please note that this covers only three compilers. It is simply not possible to test osxfuse with all compilers out there. I'm looking for a solution that is easily maintainable and does not take too much time.

Is there something like build_withinstead of fails_with?

It's not just about compilers. homebrew seems to set CFLAGS and friends as well. This resulted in various errors when building osxfuse on my test machine. Once I put ENV.remove_cc_etc in everything stated working.

Other maintainers: the fuse4x formula currently ignores our compiler selection and selects on its own, the same way that osxfuse is. My preference is for homebrew to document/control the compiler selection for osxfuse though. Thoughts?

In my opinion there is a big difference when it comes to building user space applications and libraries compared to kernel extensions. When an application crashes that's about it, the application crashed. In case a kernel extension crashes, the hole operating system goes down with it. This can result in severe data loss and effects the whole system. A package manager should not dictate the compiler or other build flags for kernel code.

Please don't take this the wrong way, but in case osxfuse is built with an incompatible compiler or incompatible build settings and causes kernel panics later on, people will be blaming osxfuse (and me), not homebrew. In my opinion letting the build script select compiler and build settings is the safest bet in this case.

[samueljohn]

Oh, actually it is not that bad, because homebrew's doctor will make sure that on each OS X the latest Xcode is installed, so when you add a fails_with :llvm block, this leaves only four different tests (10.6, 10.7, 10.8 and 10.9 all with latest Xcode). You don't have to support gcc because in homebrew it is unsupported (means on your own risk) to --use-gcc. So don't worry about that too much.
If clang is not good enough on 10.6, we can find a solution (either building a homebrew provides clang or using gcc/llvm there ... whatever works).

Also, if it is possible to write a test do ... end block, our @BrewTestBot could help with building/testing on 10.6 thruh 10.8.

In our isolated build environment, called superenv, we don't set the CFLAGS but inject or cleanup flags/args given to the compiler by providing a shim for each tool.
On Xcode-only systems Homebrew adds -isysroot, so that people that don't have the Command Line Tools for Xcode can build software. Further some aggressive optimization flags are removed. Brew prints out the removed flags.

Let me know, if - and how - I can assist you in sorting that out. What is the error you are talking about?

[bfleischer]

If clang is not good enough on 10.6, we can find a solution (either building a homebrew provides clang or using gcc/llvm there ... whatever works

clang is unsupported for everything but 10.9 builds of osxfuse. Here are the compilers the osxfuse build script selects:

• Xcode 3.2: gcc-4.2
• Xcode 4.0: gcc-4.2
• Xcode 4.1: gcc-4.2
• Xcode 4.2: llvm-gcc-4.2
• Xcode 4.3: llvm-gcc-4.2
• Xcode 4.4: llvm-gcc-4.2
• Xcode 4.5: llvm-gcc-4.2
• Xcode 4.6: llvm-gcc-4.2
• Xcode 5.0: clang

Compiler versions that do not ship with Xcode are completely unsupported.

In our isolated build environment, called superenv, we don't set the CFLAGS but inject or cleanup flags/args given to the compiler by providing a shim for each tool.
On Xcode-only systems Homebrew adds -isysroot, so that people that don't have the Command Line Tools for Xcode can build software.

The osxfuse build script does not rely on the Command Line Tools being installed. Instead it locates all Xcode installations it can find. Then selects the one, that it deems best suited for building osxfuse. Actually, multiple versions of Xcode are required for distribution builds that support Mac OS X 10.5 to 10.9.

The build script sets up its own build environment and makes use of xcrun. There should be no need to inject stuff like -isysroot or remove any flags or arguments. It builds just fine without homebrew overriding build settings. In my opinion interfering with the osxfuse build process in this way is not only dangerous but generates additional (and unnecessary) work. I'd rather spend my time on improving osxfuse than on maintinaing its homebrew formula. If you insist on removing ENV.remove_cc_etc I think it would be best to close this pull request and revisit the matter in the future.

Let me know, if - and how - I can assist you in sorting that out. What is the error you are talking about?

I don't remember exactly, but I noticed that cc (clang) was used to build osxfuse instead of the compiler that was supposed to be used (gcc, llvm-gcc). In addition to that some build flags had been changed (don't remember which ones). This caused the compiler to be very pedantic and error out. You should be able to reproduce the issues by removing ENV.remove_cc_etc and trying to build the formula yourself.

By the way, I was not able to reproduce the issues in Xcode even after switching to clang.

[mistydemeo]

I noticed that cc (clang) was used to build osxfuse instead of the compiler that was supposed to be used (gcc, llvm-gcc)

cc is actually Homebrew's wrapper, which will call the appropriately-selected tool. You can see that yourself by seeing what the value of HOMEBREW_CC is during the build. If you select a GCC/LLVM-GCC build manually, or via fails_with directives, then cc will call that compiler.

The compiler precedence you provide would be covered by:

fails_with :clang do
  build 425
end

Which would trigger precisely the compiler precedence you list above.

Re: flags, there's been some discussion about allowing formulae to turn off superenv's flag refurbishing. That would be appropriate here and would resolve the biggest problem the formula's running into.

(Though I don't think it should be active here? It's only on when the make wrapper is called, and

I'd rather spend my time on improving osxfuse than on maintinaing its homebrew formula.

And we're fine with that, but the formula needs to be maintainable to us too since we're the ones who are going to be maintaining it primarily.

[bfleischer]

And we're fine with that, but the formula needs to be maintainable to us too since we're the ones who are going to be maintaining it primarily.

That's exactly my point. It needs to be maintainable. But by interfering with the build settings the whole build process is getting much more difficult to maintain from the osxfuse end.

Xcode 3.2: gcc-4.2
Xcode 4.0: gcc-4.2
Xcode 4.1: gcc-4.2
Xcode 4.2: llvm-gcc-4.2
Xcode 4.3: llvm-gcc-4.2
Xcode 4.4: llvm-gcc-4.2
Xcode 4.5: llvm-gcc-4.2
Xcode 4.6: llvm-gcc-4.2
Xcode 5.0: clang

What are the correct fails_with statements for this?

In my opinion the main problem is not maintainability. From what I could gather so far, Homebrew is overriding build settings. I cannot count on the osxfuse formula being built the same way as the distribution package.

Can you provide a list of all the changes homebrew will make to the build settings?

[manphiz]

Or to go with raw environmental settings, "env :std" could be applied
here if desired.

On Thu, Aug 15, 2013 at 3:48 PM, Benjamin Fleischer
notifications@github.com wrote:

And we're fine with that, but the formula needs to be maintainable to us too
since we're the ones who are going to be maintaining it primarily.

That's exactly my point. It needs to be maintainable. But by interfering
with the build settings the whole build process is getting much more
difficult to maintain from the osxfuse end.

Xcode 3.2: gcc-4.2
Xcode 4.0: gcc-4.2
Xcode 4.1: gcc-4.2
Xcode 4.2: llvm-gcc-4.2
Xcode 4.3: llvm-gcc-4.2
Xcode 4.4: llvm-gcc-4.2
Xcode 4.5: llvm-gcc-4.2
Xcode 4.6: llvm-gcc-4.2
Xcode 5.0: clang

What are the correct fails_with statements for this?

In my opinion the main problem is not maintainability. From what I could
gather so far, Homebrew is overriding build settings. I cannot count on the
osxfuse formula being built the same way as the distribution package.

Can you provide a list of all the changes homebrew will make to the build
settings?

—
Reply to this email directly or view it on GitHub.

[bfleischer]

I've fixed the build script. It did detect the non-zero return code of xcodebuild but did not pass it along to homebrew.

@manphiz Could you try building HEAD and report back if homebrew detects the build failure?

[manphiz]

@bfleischer @MikeMcQuaid Retried HEAD by removing ENV.remove_cc_etc to trigger an error and the build script now can notify Homebrew that it actually failed.

[MikeMcQuaid]

@BrewTestBot test this please

[MikeMcQuaid]

Can we use https://github.com/osxfuse/osxfuse/archive/osxfuse-2.6.1.tar.gz instead here.

[bfleischer]

No, osxfuse uses submodules. Last time I cheched submodules were not contained in the tar.gz.

[MikeMcQuaid]

I'd suggest this be above the previous commands; bit confusing to say "run these commands" and then "actual run these commands before the others".

[MikeMcQuaid]

@manphiz where are we at with ENV.remove_cc_etc?

[manphiz]

@MikeMcQuaid looks like it is still needed. Without #22443 it will select gcc-4.2 as compiler, and with that it will select clang, both of which result in failure.

[manphiz]

@bfleischer Also suggest backport the patch that fixes return code:
osxfuse/osxfuse@acbd5d9

[MikeMcQuaid]

@manphiz On which platform? Perhaps we should just hardcode it there or have different fails_with rules there.

[manphiz]

@MikeMcQuaid Sorry forgot to mention. It was 10.8.

Another reason I think it should keep as-is is that after #22443 gcc-4.2 will have higher priority if installed even on 10.7 and later, which contradicts the compiler requirement. In this case, IMHO it is better to let the software choose the correct compiler.

[manphiz]

Looks like "autoconf" and "automake" should also be build dependencies, no?

[bfleischer]

@manphiz @samueljohn wrote:

for autoconf and automake, please use
depends_on :autoconf and depends_on :automake the => :build time dep is implicit there.

[manphiz]

Hmm, kinda unnecessary, but OK.

[MikeMcQuaid]

@manphiz Then can we not have a conditional fails_with for 10.7/10.8 and GCC?

[manphiz]

@MikeMcQuaid agreed. I think they are redundant now.

[bfleischer]

@MikeMcQuaid, @manphiz I have revised the caveats section and added a new tag (in the osxfuse repository) for the the recent build script fix.

[manphiz]

I'd suggest using '2.6.1.1' as version number, as '_' is will be used to mark formula revision in @jacknagel's #19920 .

[manphiz]

As per last discussion with @MikeMcQuaid, these 2 "fails_with" are not necessary given that remove_cc_etc is required for osxfuse to choose the correct compilers based on Mac OS X version with the new compiler preference in place. Please consider removing them.

[manphiz]

@bfleischer Thanks for the update. Add a few comments, which should be the last ones I hope. Also the build on 10.6 fails, please check the log.

[bfleischer]

@manphiz Changing the tag name to osxfuse-2.6.1.1 does not seem right to me because then osxfuse and homebrew would report different version numbers. osxfuse would return 2.6.1 but homebrew knows it as 2.6.1.1. This might be confusing, therefore I've explicitly set the version to 2.6.1 in the formula. We can remove this workaround once osxfuse 2.6.2 is released. I hope this is OK with you.

As for the failed build on snow leopard I'm not quite sure why this is happening. The failure is cause by the Xcode version of aclocal not respecting ACLOCAL_PATH. See #10824. But I'm pretty sure that building the formula on Snow Leopard worked in the past. Have there been recent changes to homebrew that would explain this? Is there a better workaround than using ACLOCAL instead?

[bfleischer]

I've removed the explicit version number. @BrewTestBot doesn't like it. osxfuse is identified as version 2.6.1 which should be fine.

[manphiz]

@bfleischer Sorry I wasn't clear. What I meant is that you probably want to use upstream tag like "osxfuse-2.6.1.1" in future, as "_" will be used in Homebrew's own formula revision mark. Also as you can see, it confuses Homebrew's version detection. But that's minor and temporary, and I think it is fine for now.

[manphiz]

Looks good for me now. Other maintainers? Espectially @MikeMcQuaid @mistydemeo ?

[MikeMcQuaid]

Looks good to me.

[manphiz]

Merged. Thanks.