Homebrew Recipe #5152

I have no idea if you guys are interested in this at all, and to be honest I largely threw this together locally to check out #5147, but here's a Homebrew recipe for bitcoin. It builds both the stable and HEAD branches successfully, has a self-contained berkeleydb4 to get around the issues you raise in the build documentation, and can build everything from only the command-line interface to the whole suite.

My one issue with this recipe is that Bitcoin's configure script can't find the specialised BDB4, even when the $PATH is prepended to point to it, and consequently I had to use the "--with-incompatible-bdb" option which removes the portability of the wallet. With some minor tweaks to your configure script I'm pretty sure you could get it to build with accepting this internal BDB4 though.

(Side note, If you wanted to go all out you could theoretically actually use a Homebrew recipe to build your .dmg releases as well automatically, using the 10.7 SDK, including building internally all the dependencies, but that's a whole other ballgame we can talk about if desired later).

Anyway, If you want it, here it is. If not, never mind :grinning:.

I appreciate the effort, but I'm having a hard time seeing how the pro's could outweigh the con's. Maybe you have some use-case in mind that I'm not considering? As it stands, users are either downloading a dmg, or building themselves. Adding a hybrid 3rd option will only complicate things further, and OSX is hard enough to maintain as it is.

Adding to that, there are some things that a distributed dmg provides, disabling app-nap for example.

As for a recipe to create a dmg, we already have that with our depends system:

$ make -C depends
$ ./autogen.sh
$ ./configure --prefix=`pwd`/x86_64-apple-darwin*
$ make deploy

Again, I'm having a hard time seeing how involving homebrew would be beneficial.

It isn't intended necessarily for Bitcoin themselves, but rather end users. It is the "building themselves" crowd that I had in mind here, especially on OS X, given your build documentation for users involves Homebrew already, and internalising everything into one script helps reduce variables that crop up as in #5147. This is a kind of extension of your build documentation, but reduces the amount end users have to do and the places where that can go wrong to nil. (Theoretically).

I wasn't deliberately proposing a third option, my opinion was more "Hey, this could be your building yourself option for OS X".

I don't have anything against pre-distributed dmg files at all, and I'd certainly generally desire and urge people to use those instead of building the tools here themselves, but this being the crypto world there is always going to be an element who stare at pre-distributed binaries with some suspicion.

My point largely was that you already involve Homebrew in your documentation for osx, so this is just an extension of that, but as I said, I only really threw this together to check there wasn't any SSLv2 errors on Homebrew's end of the deal for #5147, and it just occurred to me afterwards that it might be useful for that minority of users on OS X who decide to build these things themselves instead of trusting a dmg.

(Again, I have no beef against signed distributed binaries).

Well, I'd argue that most people building themselves on OSX are doing so because they're hacking on something.

For those who wish to build while ruling out dependency problems, or build using the release-build process, we should encourage them to use our depends. Maybe the (lack of) documentation is the core issue here?

I wouldn't disagree with your assessment there at all. Indeed, half the confusion when I was looking into #5147 was "Bitcoin have this incredible self-building dependency system, why are they using Homebrew?" and then "If they're using Homebrew, why aren't they using the full power of Homebrew to fully automate the build process on OS X for those who prefer to build from source?".

IMO, You have two incredible systems, Homebrew and your internal dependency build-process, and the current documentation seems to conflict over which people should use. Homebrew is incredible, and the internal-dependency system is incredible, but melding the two together is a confusing choice.

(None of this is a critique of the team here. You guys consistently smash it out of the park).

Yea, that's the right question to be asking IMO. I see no problem with building both ways, but some documentation stating the pros/cons of each method would probably go a long way.

Certainly. Some indication as to which is better for what circumstance and the issues around each would help. I understand OS X support is a pain to maintain, entirely. Happy for this to be closed if desired.

For those who wish to build while ruling out dependency problems or build using the release-build process, we should encourage them to use our depends.

Not sure how using this formula is different? Just makes the job simpler and less time spent config'ing.

We already have homebrew instructions in doc/build-osx.md. So I'm not opposed to merging this if this makes things easier for MacOSX developers. Please do add mention of this in the Homebrew instructions though.

Alright, I've pushed some instructions on the script into the build-osx documentation. Let me know how people feel about it, whether it needs honing further, etc.

@laanwj Please no. This doesn't help OSX devs, it's more for quasi-end-users. It's the equivalent of "apt-get install bitcoin" for OSX. Even worse, it could end up "bottled", meaning that pre-built binaries would just be fetched and installed.

Devs build from source, end-users download releases. This just adds another build-path for us to maintain without any real benefit.

Alright. Look, I have no say here, this is down to you guys. If you want it in, I'll make whatever changes you see fit.

Note that Homebrew will almost certainly never accept a bitcoind formula into the core, so there is zero chance of this ever being "bottled". Bottles are only generated by the core formulae and certain specific other taps. Bottles are not generated for every formulae in every tap, Homebrew doesn't have the resources to quite manage that I suspect.

You can also add an extremely simple build-flag to the instructions to ensure every dependency is built-from-source as well, so everything comes by source. It takes longer, but if you want source that's something Homebrew can bend to extremely easily.

@theuni OK @DomT4 Maybe it would be an idea to publish+maintain this elsewhere, outside the repository? Ie in a gist? We can't take up maintaining another MacOSX build path, but there's no one holding you back from doing that yourself.

Sure, I can set up a Homebrew-crypto tap of sorts. There was quite a popular one maintained by someone else previously, but the owner there seems to have ceased updating it. I don't mind setting one up, It'll be fairly low maintenance for me unless Bitcoin change build process dramatically.

Alright, It's over here if anyone wants it in future or someone comes looking for it through this thread.

@DomT4 Instead of messing with PATH for bdb, you need to be setting cppflags/ldflags as args to configure. Something like:

 args = ["--prefix=#{prefix}",
"--disable-dependency-tracking",
"CPPFLAGS=-I#{prefix}/berkeley-db4/4.8.30/include",
"LDFLAGS=-L#{prefix}/berkeley-db4/4.8.30/lib"
]

There may be a more homebrew-ish way to accomplish that, though. Then you won't need --with-incompatible-bdb. I'm actually not sure how it currently works. If it builds but finds a different bdb version, surely it's finding one already installed somewhere?

Yeah, I tried that, but it wasn't particularly interested and still flagged the incompatible to me, frustratingly. The PATH ENV setting does something similar, it just moves the internal BDB4 location to the front of the PATH so the build script finds it first and foremost. (For the duration of the build script).

There are various ways to try and stop it finding another elsewhere, which I'll try, but I'm not sure if the way the configure script determined the BDB4 dependency, BREW --prefix berkeley-db4 is breaking that. It's a perfectly valid and solid way of finding the BDB4 dependency for Bitcoin, but it can be a pain in terms of if you use Homebrew but have the BDB4 you want to use elsewhere.

If I can't get it to take flags or PATH temporary amendments without still bumping into the issue I may end up inserting a tiny patch to the configure script in the formula on my end to ensure it finds our BDB4 instead of Homebrew's default.

@DomT4 Confirmed working here with the changes described above. It seems homebrew removes itself from $PATH so that our 'brew' stuff never runs anyway. But it sets it up the same way we would have.

As I mentioned before, there's no need to mess with the PATH for bdb, it's never used. Only the includes/libs matter. Here's a working version with no patching required: http://pastebin.com/raw.php?i=yLtbzzug

@theuni Huh, that's strange. It wasn't working when I set those flags inside the Homebrew environment, we set flags a little differently to how you have there, but heck, if it works I'll take it. Thanks!