Please convert CPU/ARCH specific USE flags to cpu_flags_<arch>_<flag> for clarity. Thanks! Reproducible: Always
Created attachment 395170 [details, diff] metadata.xml.patch
Created attachment 395172 [details, diff] ffmpeg-1.2.11.ebuild.patch The relevant par is: -- ARM_CPU_FEATURES=(neon) PPC_CPU_FEATURES=(altivec) SPARC_CPU_FEATURES=(vis) X86_CPU_FEATURES=(3dnow:amd3dnow 3dnowext:amd3dnowext avx mmx mmxext ssse3) CPU_FEATURES=() for arch in {ARM,PPC,SPARC,X86}; do eval CPU_FLAGS=\"\${${arch}_CPU_FEATURES[@]}\" for flag in ${CPU_FLAGS}; do cpu_flag=cpu_flags_${arch,,[A-Z]}_${flag%:*} eval has "${flag%:*}" "\${CPU_FLAGS_${arch}}" && IUSE+=" +${cpu_flag}" || IUSE+=" ${cpu_flag}" CPU_FEATURES+=(${cpu_flag}:${flag#*:}) done done unset {ARM,MIPS,PPC,X86}_CPU_FEATURES CPU_FLAGS arch {cpu_,}flag -- and a few edit/update to accomodate to the new format. PS: 1.2 should be edited to include FFMPEG_SUBSLOT=52.54.54 like the other ebuilds. I could not make a clean patch including those few lines... without touching too many lines. Most of the minor edit/clean up could be thrown away.
Created attachment 395174 [details, diff] ffmpeg-2.2.11.ebuild.patch Same (as above.) And manual edit of `mmx?' to `cpu_flags_x86_mmx?' should be done... because I could not include it in the patch--divergence of edit! sorry for this.
Created attachment 395176 [details, diff] ffmpeg-2.5.3.ebuild.patch Same (as above,--first ebuild patch.)
Off topic: (if the maintainer ever notice this) why not include ebuilds with <major>.<minor>.9999? Easily done, because ffmpeg has branches for each minor version. I can provide those if necessary. Thanks!
Almost forget about it... of course ARM & MIPS flag name can be changed... I just avoided having double arm in the name (pointless) and mips could gain a full name with (dsp-ase-r2 or something along the lines)--I went the short way.
Created attachment 395198 [details, diff] metadata.xml.patch I wasn't careful enough for the metadata... with space or tab intertwined together in a messy fashion; and too long sentences. Well, fixed. Complete clean up of the file. (Maybe I forgot a thing or two.) NOTE: The previous ebuild patches lack any `DOCS=( Changelog README CREDITS doc/APIchanges doc/RELEASE_NOTES ) ' which should be added... at hand. Sorry for this! (Two manual EDIT required then.) Thanks!
@MIPS/ARM/PPC: Could you give any feedback of the cpu_flags_(arm|ppc|mips)_<flag>s? Please read the previous posts. Thanks!
wowowowowow, there are way too much unrelated changes here, some are even wrong mgorny pastebin'ed me a patch i liked much more also, please don't try to force your style (bash arrays everywhere) when it is certainly not needed.
(In reply to Alexis Ballier from comment #9) > wowowowowow, there are way too much unrelated changes here, some are even > wrong > > mgorny pastebin'ed me a patch i liked much more > > also, please don't try to force your style (bash arrays everywhere) when it > is certainly not needed. No problem, comment #1 said it all (already.)
(In reply to tokiclover from comment #10) > (In reply to Alexis Ballier from comment #9) > > wowowowowow, there are way too much unrelated changes here, some are even > > wrong > > > > mgorny pastebin'ed me a patch i liked much more > > > > also, please don't try to force your style (bash arrays everywhere) when it > > is certainly not needed. > > No problem, comment #1 said it all (already.) Of course, the content of comment #1 could refactored easily to use plain variable name instead of arrays. (Just a proposal of it, no more no less.) Well, what about the <major>.<minor>.9999 proposal? Shame, LIBAV has those and it won't be a maintainance burden because there no noticeable change but bug fixes on patch-levem bump. So, what do you think about it?
(In reply to tokiclover from comment #11) > Well, what about the <major>.<minor>.9999 proposal? Shame, LIBAV has those > and it won't be a maintainance burden because there no noticeable change but > bug fixes on patch-levem bump. So, what do you think about it? nothing prevents it, but ffmpeg is more on the "release early, release often" way of things, meaning backports are usually done in bunch then a new release is tagged so there isn't much gain in it
x86 in tree now. We'll start working on other arches in a few days.
