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

Support Boost 1.49 in core, side-by-side with boost-current #15299

Closed
adamv opened this Issue Oct 4, 2012 · 24 comments

Comments

Projects
None yet
7 participants
@adamv
Contributor

adamv commented Oct 4, 2012

Goes against policy, but suggest we add "Boost149" to core, side-by-side with Boost (as moving current version), to deal with software that hasn't updated past 1.49 yet.

I think it is better to unbreak existing formulae and allow new ones in that need this version of Boost than it is to be broken/obstructionist.

Someone tell me why this is actually a Bad Idea.

@MikeMcQuaid

This comment has been minimized.

Show comment Hide comment
@MikeMcQuaid

MikeMcQuaid Oct 4, 2012

Member

I'd love another solution if there is one but this is better than just having broken stuff stay broken.

Member

MikeMcQuaid commented Oct 4, 2012

I'd love another solution if there is one but this is better than just having broken stuff stay broken.

@jacknagel

This comment has been minimized.

Show comment Hide comment
@jacknagel

jacknagel Oct 4, 2012

Contributor

I suggest we stick it in versions and add depends_on 'homebrew/versions/boost149' where necessary. Should probably be keg-only.

Contributor

jacknagel commented Oct 4, 2012

I suggest we stick it in versions and add depends_on 'homebrew/versions/boost149' where necessary. Should probably be keg-only.

@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Oct 4, 2012

Contributor

Definitely keg-only. Will the external depends_on work correctly or is it relatively untested?

Contributor

adamv commented Oct 4, 2012

Definitely keg-only. Will the external depends_on work correctly or is it relatively untested?

@mistydemeo

This comment has been minimized.

Show comment Hide comment
@mistydemeo

mistydemeo Oct 4, 2012

Contributor

It works but is a little clunky; it halts the build and prompts the user to manually tap the repo then retry. If we're going to depend on external repos from core, should probably autotap the repo for the user.

Contributor

mistydemeo commented Oct 4, 2012

It works but is a little clunky; it halts the build and prompts the user to manually tap the repo then retry. If we're going to depend on external repos from core, should probably autotap the repo for the user.

@MikeMcQuaid

This comment has been minimized.

Show comment Hide comment
@MikeMcQuaid

MikeMcQuaid Oct 4, 2012

Member

We could use this as an excuse to make auto-tap work I guess?

Member

MikeMcQuaid commented Oct 4, 2012

We could use this as an excuse to make auto-tap work I guess?

@Sharpie

This comment has been minimized.

Show comment Hide comment
@Sharpie

Sharpie Oct 4, 2012

Contributor

Auto-tapping was in my original design. I think it was probably changed to manual tapping due to the way tapping a repo overwrites formulae with symlinks.

The original design used subdirectory searches instead of symlinks so this wasn't an issue.

Just curious: how long is the list of formulae broken by newer Boost libraries?

Contributor

Sharpie commented Oct 4, 2012

Auto-tapping was in my original design. I think it was probably changed to manual tapping due to the way tapping a repo overwrites formulae with symlinks.

The original design used subdirectory searches instead of symlinks so this wasn't an issue.

Just curious: how long is the list of formulae broken by newer Boost libraries?

@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Oct 4, 2012

Contributor

Half a dozen that we know of (including existing and new submissions)

Contributor

adamv commented Oct 4, 2012

Half a dozen that we know of (including existing and new submissions)

@jacknagel

This comment has been minimized.

Show comment Hide comment
@jacknagel

jacknagel Oct 4, 2012

Contributor

IMO any enhancements to brew-tap should really start with someone typing "class Tap". Trying to go any further using strings as the canonical representation is just going to make fixing this more painful in the future.

Contributor

jacknagel commented Oct 4, 2012

IMO any enhancements to brew-tap should really start with someone typing "class Tap". Trying to go any further using strings as the canonical representation is just going to make fixing this more painful in the future.

@manphiz

This comment has been minimized.

Show comment Hide comment
@manphiz

manphiz Oct 21, 2012

Contributor

How about create boost149 in core first and move to tap after auto-tap is implemented?

Also, I wonder how one can get the path to opt (#{HOMEBREW_PREFIX}/opt/#{Formula}) in brew formula? Formula.factory '#{Formula}' will return the path in #{Cellar} which is not idea and prune to break when upgrading. Or Formula.factory implementation could be changed to return that path instead?

Contributor

manphiz commented Oct 21, 2012

How about create boost149 in core first and move to tap after auto-tap is implemented?

Also, I wonder how one can get the path to opt (#{HOMEBREW_PREFIX}/opt/#{Formula}) in brew formula? Formula.factory '#{Formula}' will return the path in #{Cellar} which is not idea and prune to break when upgrading. Or Formula.factory implementation could be changed to return that path instead?

@jacknagel

This comment has been minimized.

Show comment Hide comment
@jacknagel

jacknagel Oct 21, 2012

Contributor

Also, I wonder how one can get the path to opt (#{HOMEBREW_PREFIX}/opt/#{Formula}) in brew formula?

Formula.factory("foo").opt_prefix
Contributor

jacknagel commented Oct 21, 2012

Also, I wonder how one can get the path to opt (#{HOMEBREW_PREFIX}/opt/#{Formula}) in brew formula?

Formula.factory("foo").opt_prefix
@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Oct 24, 2012

Contributor

Progress: https://github.com/adamv/homebrew/compare/boost

Mira compiles again.

Please comment.

Contributor

adamv commented Oct 24, 2012

Progress: https://github.com/adamv/homebrew/compare/boost

Mira compiles again.

Please comment.

@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Oct 24, 2012

Contributor

I'll need to nuke the old bottles, as they will have the wrong install names...

Contributor

adamv commented Oct 24, 2012

I'll need to nuke the old bottles, as they will have the wrong install names...

@manphiz

This comment has been minimized.

Show comment Hide comment
@manphiz

manphiz Oct 24, 2012

Contributor

I have another pull request against boost current at mxcl#15506, in which I hope the change of icu4c prefix (uses Formula.factory('icu4c').opt_prefix instead) can be incorporated here to avoid future breakage when updating icu.

Contributor

manphiz commented Oct 24, 2012

I have another pull request against boost current at mxcl#15506, in which I hope the change of icu4c prefix (uses Formula.factory('icu4c').opt_prefix instead) can be incorporated here to avoid future breakage when updating icu.

@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Oct 24, 2012

Contributor

@manphiz OK, any changes to the most-recent Boost formula will be made to 1.49, if needed.

Contributor

adamv commented Oct 24, 2012

@manphiz OK, any changes to the most-recent Boost formula will be made to 1.49, if needed.

@manphiz

This comment has been minimized.

Show comment Hide comment
@manphiz

manphiz Oct 24, 2012

Contributor

@adamv Cool. thanks.

Contributor

manphiz commented Oct 24, 2012

@adamv Cool. thanks.

@2bits

This comment has been minimized.

Show comment Hide comment
@2bits

2bits Oct 25, 2012

Contributor

I am not in favor of auto tapping. In the case of versions with distinct names, it's not such a big deal. But with homebrew/dupes it seems risky.

Contributor

2bits commented Oct 25, 2012

I am not in favor of auto tapping. In the case of versions with distinct names, it's not such a big deal. But with homebrew/dupes it seems risky.

@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Oct 25, 2012

Contributor

@2bits can you review my commit above?

Contributor

adamv commented Oct 25, 2012

@2bits can you review my commit above?

@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Oct 25, 2012

Contributor

Maintainers, contributors, please let me know if this commit is a "bad idea".

I see it as a hack, but a useful one, as I'm certainly not going to maintain patched versions of things that depend on 1.49 myself.

Contributor

adamv commented Oct 25, 2012

Maintainers, contributors, please let me know if this commit is a "bad idea".

I see it as a hack, but a useful one, as I'm certainly not going to maintain patched versions of things that depend on 1.49 myself.

@2bits

This comment has been minimized.

Show comment Hide comment
@2bits

2bits Oct 26, 2012

Contributor

I think people concur this is reasonable and gets things working. I couldn't apply the mira part of your branch, but that's not a big deal. I'm testing it now. If something doesn't work I'll let you know.

Contributor

2bits commented Oct 26, 2012

I think people concur this is reasonable and gets things working. I couldn't apply the mira part of your branch, but that's not a big deal. I'm testing it now. If something doesn't work I'll let you know.

@mistydemeo

This comment has been minimized.

Show comment Hide comment
@mistydemeo

mistydemeo Oct 26, 2012

Contributor

Looks good to me, and certainly preferable to breaking a lot of packages in core. We can shuffle it off to dupes once very little depends on it, in the absence of autotap.

Contributor

mistydemeo commented Oct 26, 2012

Looks good to me, and certainly preferable to breaking a lot of packages in core. We can shuffle it off to dupes once very little depends on it, in the absence of autotap.

@MikeMcQuaid

This comment has been minimized.

Show comment Hide comment
@MikeMcQuaid

MikeMcQuaid Oct 26, 2012

Member

Seems reasonable to me. We could/should consider doing this for other popular stuff in the versions repo.

Member

MikeMcQuaid commented Oct 26, 2012

Seems reasonable to me. We could/should consider doing this for other popular stuff in the versions repo.

@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Oct 26, 2012

Contributor

Re-pushed here with today's boost tweaks and removed mira which now works as normal.

Contributor

adamv commented Oct 26, 2012

Re-pushed here with today's boost tweaks and removed mira which now works as normal.

@mistydemeo

This comment has been minimized.

Show comment Hide comment
@mistydemeo

mistydemeo Oct 26, 2012

Contributor

@MikeMcQuaid No, I think we should only do this for anything that's a dependency of multiple pieces of software in Homebrew. Most of what's in versions are older versions of software which certain people need for their dev stack, but which no software in core requires. boost is a special case.

Contributor

mistydemeo commented Oct 26, 2012

@MikeMcQuaid No, I think we should only do this for anything that's a dependency of multiple pieces of software in Homebrew. Most of what's in versions are older versions of software which certain people need for their dev stack, but which no software in core requires. boost is a special case.

@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Oct 27, 2012

Contributor

Pushed in to core.

Contributor

adamv commented Oct 27, 2012

Pushed in to core.

@adamv adamv closed this Oct 27, 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.