This repository has been archived by the owner. It is now read-only.

Add depends_on "something" => :universal #4257

Closed
adamv opened this Issue Feb 15, 2011 · 25 comments

Comments

Projects
None yet
4 participants
Contributor

adamv commented Feb 15, 2011

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.

Owner

MikeMcQuaid commented Feb 15, 2011

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

Contributor

adamv commented Mar 16, 2011

"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.

Contributor

adamv commented Mar 16, 2011

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.

Contributor

adamv commented Mar 16, 2011

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

Nothing to see yet.

Owner

MikeMcQuaid commented Mar 16, 2011

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.

Contributor

adamv commented Mar 16, 2011

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

Owner

MikeMcQuaid commented Mar 16, 2011

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

Contributor

adamv commented Mar 16, 2011

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

Owner

MikeMcQuaid commented Mar 16, 2011

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

@ghost ghost assigned adamv Apr 13, 2011

Sharpie added a commit that referenced this issue Oct 5, 2011

martinploeger added a commit to martinploeger/homebrew that referenced this issue Oct 8, 2011

Contributor

adamv commented Nov 28, 2011

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.

Contributor

Sharpie commented Nov 28, 2011

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?.

Contributor

Sharpie commented Nov 28, 2011

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.

Contributor

jacknagel commented Nov 28, 2011

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.

Contributor

adamv commented Nov 28, 2011

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

Contributor

adamv commented Nov 28, 2011

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

Contributor

Sharpie commented Nov 29, 2011

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.

Contributor

Sharpie commented Nov 29, 2011

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.

Owner

MikeMcQuaid commented Nov 29, 2011

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.

Contributor

jacknagel commented Dec 1, 2011

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.

Contributor

adamv commented Dec 1, 2011

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.

Contributor

jacknagel commented Dec 1, 2011

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.

Owner

MikeMcQuaid commented Dec 1, 2011

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?

Contributor

Sharpie commented Dec 1, 2011

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

Owner

MikeMcQuaid commented Jan 12, 2012

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

Contributor

adamv commented Aug 6, 2012

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

@adamv adamv closed this Aug 6, 2012

Sharpie added a commit to Sharpie/homebrew that referenced this issue Sep 12, 2012

snakeyroc3 pushed a commit to snakeyroc3/homebrew that referenced this issue Dec 17, 2012

@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 16, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.