Add depends_on "something" => :universal

[adamv]

Wine only builds 32-bit, so it needs its deps to be compiled w/ 32-bit support. Except that those deps are also used by 64-bit brews, so the deps need to be built in Universal mode.

Wine should be able to flag its deps as :universal; the brew build system should be able to trickle that down to deps-of-deps.

[MikeMcQuaid]

Also, it should reinstall dependencies automatically if it needs to. This will hopefully let us disable universal-by-default just for Wine. Good idea.

[adamv]

"def check_neon_arch" in the Subversion formula gives a hint of how this would work.

Formulae that need to be ":universal" deps will need to expose a "key library" file that can be tested for its arches, so it would require a DSL addition.

Formula's "installed?" could also gain an optional keyword parameter...I'll work up a patch.

[adamv]

In formula, "def recursive_deps" and "def self.expand_deps" will need to be able to return the dep formula PLUS a list of attributes for that dep.

[adamv]

Work progressing in: https://github.com/adamv/homebrew/tree/universal

Nothing to see yet.

[MikeMcQuaid]

Hmm. I'm not sure I like the neon approach as it special-cases universal when we'll need the same approach for multiple options. In my mind we may as well do it properly first time. Could we not write an options file out somewhere and just query that (e.g. Options/formula-name)? If not, could we require options to define a function that has a more generic test? The first seems a lot easier to implement and maintain.

[adamv]

My thinking was getting it working for Universal first, in a branch, and then generify after that, before merging.

[MikeMcQuaid]

Fair enough. I guess I'm just dubious about this approach working for anything except universal.

[adamv]

We're going to need deps to carry their options (we'll need to be able to do depends_on 'thing' => [:foo1, :foo2] into the install phase; turns out we essentially throw away the recommended/optional flags.

We'll need to keep around the dep flags for instance to handle this: https://github.com/mxcl/homebrew/issues/#issue/1604

[MikeMcQuaid]

Yeh, I agree with throwing away those flags too (although build-time is worth keeping to e.g. cleanup).

[adamv]

Now that we have install receipts I can sniff for --universal in the install options rather than the "pick a library or exe and use file to sniff the arch" route I was going down before.

I'll try to see if any of my previous dep improvement work can be cherry picked.

[Sharpie]

I'll try to see if any of my previous dep improvement work can be cherry picked.

I think the depends_on 'thing' => [:foo_1, :foo_2] approach sounds viable. The Symbols could be translated to --foo-1 and --foo-2, then fed to Tab.installed_with?.

[Sharpie]

Also note that I recently re-worked how the FormulaInstaller class handles dependency installation in 3edc9d2. Installation now happens in a block that temporarily modifies ARGV. ARGV.filter_for_dependencies` could be extended such that it accepted an optional list of additional flags to add during installation.

[jacknagel]

Now that we have install receipts I can sniff for --universal in the install options rather than the "pick a library or exe and use file to sniff the arch" route I was going down before.

This will also need to handle brews that build universal by default. Maybe we can just convert them to ENV.universal_binary if ARGV.build_universal? since they will be built/rebuilt as universal when needed.

[adamv]

ENV.universal_binary needs to be able to add --universal to the receipt, perhaps.

[adamv]

Or an "always universal" flag gets added to the DSL.

[Sharpie]

ENV.universal_binary needs to be able to add --universal to the receipt, perhaps.

The current method of recording formula options sniffs ARGV, which can't be modified in install because the process is forked at that point. The setup also requires the option to be declared using options.

There are probably better ways of doing it, but this is the best I could come up with that didn't require an invasive re-write. I think adding more DSL elements beyond options that affect the Metadata could complicate things in a hurry. Perhaps we could extend the options array to allow for an optional attributes component? A possible value could be :default.

[Sharpie]

I think adding more DSL elements beyond options that affect the Metadata could complicate things in a hurry.

Clarification: more DSL elements that affect the same piece of Metadata.

[MikeMcQuaid]

Perhaps it's worth reconsidering why we have the "always universal" brews. If I remember correctly originally it was just to workaround the fact we couldn't depend on universal flags. If this problem is now gone the need for them may be too.

[jacknagel]

Here's where MacPorts is at on this (well, a year ago anyway):

http://article.gmane.org/gmane.os.apple.macports.devel/12361

tl;dr They used to run lipo -info on files to determine whether or not to rebuild dependencies; that's why some Portfiles have an "archcheck.files" list. Now they just look at metadata.

I agree with Mike that once we can specify universal dependencies we probably don't need universal-by-default builds.

[adamv]

I sure as heck wouldn't want a surprise rebuild of Boost or Qt because they came on 64-bit and then needed to be 32-bit too. Me still on Snow Leopard and not downloading pre-built bottles.

[jacknagel]

I sure as heck wouldn't want a surprise rebuild of Boost or Qt because they came on 64-bit and then needed to be 32-bit too.

Okay, sure, but neither of those currently build universal by default, so under the current scheme they would be rebuilt anyway.

After some dumb grep'ing through the formula I count between 14-17 that build universal unconditionally, and I don't think any of them have inconveniently long build times.

Me still on Snow Leopard and not downloading pre-built bottles.

Slightly off-topic but for a while I was cheating and just disabling the Lion check in ARGV.build_from_source? so that I could use bottles. Though the last few haven't been universal so I had to build from source anyway.

[MikeMcQuaid]

Wine doesn't need to build Boost or Qt though? I do think we should get rid of universal-only brews and just rebuild e.g. Wine dependencies. There will be less people building WINE than building their dependencies.

Perhaps we should try and extend Bottle support now that it seems to be working well to be a) always universal b) support 10.6 c) support more formulae.

Thoughts?

[Sharpie]

Definitely a +1 on extending bottles to support multiple MacOS versions. This has been on my TODO list for a while.

[MikeMcQuaid]

We have option tracking now so this is starting to look more likely.

[adamv]

I would like to close this as it is written, and possibly some related ones, and write a new proposal for universal support.