Opened 13 years ago

Closed 13 years ago

#32506 closed update (fixed)

x264: Update to 20111210 and add static library

Reported by: marin.saric@… Owned by: dbevans (David B. Evans)
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: haspatch Cc: jeremyhu (Jeremy Huddleston Sequoia)
Port: x264

Description

A simple version update including an addition of a compile flag to create a static version of libx264, as is common for other libraries in MacPorts.

Attachments (3)

Portfile-x264.diff (950 bytes) - added by marin.saric@… 13 years ago.
x264 Portfile update, new version, adding a static build
patch-bump-dependent-port-revisions.diff (3.5 KB) - added by marin.saric@… 13 years ago.
A patch to bump the revision number of all of the ports that depend on x264. This patch is applied from the top of the ports tree.
bump_dep_revs.sh (3.2 KB) - added by marin.saric@… 13 years ago.
A tool to find all ports that depend on a given port and produce a patch file that bumps their revisions. The local Portfile whitespace style is emulated.

Download all attachments as: .zip

Change History (12)

Changed 13 years ago by marin.saric@…

Attachment: Portfile-x264.diff added

x264 Portfile update, new version, adding a static build

comment:1 Changed 13 years ago by marin.saric@…

BTW, libx264 has a quickly changing interface with somewhat less stable versioning than other libraries. The ABI (compiled-level API) changed between this and last version.

ffmpeg needs a recompile, which is achieved with

port -nR upgrade --force x264

Should ffmpeg's revision number be bumped so that this recompile is acheived automatically?

comment:2 in reply to:  1 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: devans removed
Keywords: haspatch added
Owner: changed from macports-tickets@… to devans@…

Replying to marin.saric@…:

Should ffmpeg's revision number be bumped so that this recompile is acheived automatically?

Absolutely, as should any other ports depending on x264's library.

Changed 13 years ago by marin.saric@…

A patch to bump the revision number of all of the ports that depend on x264. This patch is applied from the top of the ports tree.

Changed 13 years ago by marin.saric@…

Attachment: bump_dep_revs.sh added

A tool to find all ports that depend on a given port and produce a patch file that bumps their revisions. The local Portfile whitespace style is emulated.

comment:3 Changed 13 years ago by marin.saric@…

I hope that the bump_dev_revs.sh tool is going to be useful in the future as well. It is self-contained and does not hardcode anything.

I am attaching it in hope it can be stashed together with other utilities, wherever they might reside currently.

comment:4 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Summary: Updating x264 to 20111210, adding a static buildx264: Update to 20111210 and add static library

Thanks for bump_dev_revs.sh. Probably the contrib directory would be a good place for us to put this. I see that you only look for dependencies of the form port:portname, but note that although they're not as common we also allow dependencies of the form path:some/path:portname, bin:someprogram:portname and lib:somelibrary:portname.

comment:5 Changed 13 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Also, what's the reasoning behind including the static library? I'd certainly prefer to eliminate static libraries across the board rather than adding new ones...

comment:6 Changed 13 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Cc: jeremyhu@… added

Cc Me!

comment:7 Changed 13 years ago by marin.saric@…

With regards to Jeremy's question about static libraries. Definitely a good question and it depends on what aspect you are looking at.

There are a ton of static libraries built by MacPorts already, so I think it would be consistent to provide them for all ports offering it until there is an explicit policy by MacPorts that says that MacPorts does not support static libraries.

x264 particularly benefits from a static deployment as it eliminates the problem like this one if the client links against it statically.

How about this:

Can we have a separate discussion of whether static libraries in MacPorts are useful? I am posting my answer to your good question in macports-dev.

comment:8 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

The existing MacPorts policy is to provide both dynamic and static libraries. Discussions about changing that policy should occur on macports-dev.

comment:9 Changed 13 years ago by raimue (Rainer Müller)

Resolution: fixed
Status: newclosed

Maintainer timeout, committed in r90303.

Note: See TracTickets for help on using tickets.