Build libvpx on non-Mac POSIX platforms

libvpx.gyp

Index: libvpx.gyp
diff --git a/libvpx.gyp b/libvpx.gyp
index 9fce1083420f278ee02b8ae6251a9471c0df6911..2a065ae2522f76957039cff656e1a59dce6e1855 100644
--- a/libvpx.gyp
+++ b/libvpx.gyp
@@ -13,7 +13,7 @@
     ],
   },
   'conditions': [
-    [ '(OS=="linux" or OS=="mac" or OS=="win") and target_arch!="arm"', {
+    [ 'OS != "android" and target_arch != "arm"', {
       'targets': [
         {
           # This libvpx target contains both encoder and decoder.
@@ -22,8 +22,17 @@
           'type': 'static_library',
           'variables': {
             'yasm_output_path': '<(SHARED_INTERMEDIATE_DIR)/third_party/libvpx',
+            'variables': {
+              'conditions': [
+                ['os_posix == 1 and OS != "mac"', {
+                  '_OS%': 'linux',

[Ami GONE FROM CHROMIUM, 2011/11/23 09:14:11]

I'm shocked that reusing the linux config happens to work.
I'm not aware of any invariants that imply that posix&&!mac implies one of
linux,freebsd,openbsd,solaris (and I fear that others can slide in here) so your
testing is insufficient for this technique.

What are you trying to accomplish?  If it's just to enable the 3 systems you
checked, why not test for exactly those?

FWIW since there are no bots for those OSs odds are pretty good that in the
future these setups will silently break.  I wonder why you want this in the
first place :)  (AFAIK only remoting/ using libvpx; have you got that working on
one of {free,open}bsd/solaris?

[ruben, 2011/11/23 10:07:41]

The linux and mac ia32 configs only differ by 6 lines, so I don't think it's
that surprising that other POSIX platforms also work. :) Obviously the os_posix
would be open-ended for other POSIX platforms, but that's sort of the point, to
leave it open for future ports.  The gyp file for ffmpeg has a similar setup and
I've been making the same switch all over Chromium, to make future POSIX ports
easier.  Since none of these POSIX platforms are officially supported, I don't
think it much matters if it breaks.
Yep, it may break.  I assumed that libvpx was still being used by ffmpeg/, but
now that you mention it, I see that the patched-ffmpeg recently switched to
using its own vp8 decoder.  remoting/ compiles but I have never tried it, while
webrtc hasn't been ported to these other POSIX platforms.  You're probably right
that libvpx is useless for these other platforms, but I suppose this patch can
be included just for completeness?  If you think not, I'll remove it.

[Ami GONE FROM CHROMIUM, 2011/11/23 17:03:39]

It would be interesting to know whether the other platforms generate different
configs from the linux one (i.e. whether using the linux configs on them is
likely to cause subtle bugs or perf degradation).
ISTM that you would be doing those platforms a disservice, having them build
stuff they're not using.

[ruben, 2011/11/23 18:55:53]

The library is only compiled at this point, so no way to know.  I think it was
compiled AND used by ffmpeg at one point, if so, it worked fine on these other
platforms then.
Not really as libvpx is a quick compile.  The alternative is to write another
patch to really disable remoting- I say "really" since unsetting the remoting
flag still causes an unmodified libvpx.gyp to be called from remoting.gyp and
then gyp fails- so it's really a question of whether remoting should be disabled
by default on other platforms.  I've been compiling it because it does build
with this patch, but if you think it's better that remoting is disabled on other
platforms, I'll submit a patch for that instead.

My preference is to compile as much Chromium code by default as possible, hence
this patch, but I don't even know what remoting is for so I'm fine with just
removing it also.

[Ami GONE FROM CHROMIUM, 2011/11/23 19:09:43]

FTR chromium switched from libvpx to ffvp8 for video decode in CL 97421.
Ah; sounds like you ran into a non-ARM version of
http://code.google.com/p/chromium/issues/detail?id=94418

(remoting is part of the implementation of
https://chrome.google.com/webstore/detail/gbchcmhmhahfdphkhkmpfmihenigjmpp)

I think you've convinced me, with the proviso that there should be an
explanatory comment (both b/c the technique is tricksy and because it might lead
people to believe there's a bigger support commitment than there really is).
WDYT of:
# HACK: freebsd/openbsd/solaris seem to build fine using linux's configs
# so we use them here.  Use of these headers on anything other than linux
# is likely to break (unsupported platform and no bots).  YMMV.

[ruben, 2011/11/23 19:33:12]

Yeah, after you mentioned it earlier, I checked that myself.  However, when I
submitted this patch, I was under the incorrect impression ffmpeg was still
using libvpx.
 
Yeah, looks like it.
OK, I missed the news of that release and a quick google search didn't turn it
up.  Maybe I'll try that extension later and see if it works on these
unsupported platforms. :)
Will do.

+                }, {
+                  '_OS%': '<(OS)',
+                }],
+              ]},
+            '_OS%': '<(_OS)',
             'yasm_flags': [
-              '-I', 'source/config/<(OS)/<(target_arch)',
+              '-I', 'source/config/<(_OS)/<(target_arch)',
               '-I', 'source/libvpx',
             ],
           },
@@ -31,7 +40,7 @@
             '../yasm/yasm_compile.gypi'
           ],
           'include_dirs': [
-            'source/config/<(OS)/<(target_arch)',
+            'source/config/<(_OS)/<(target_arch)',
             'source/libvpx',
             'source/libvpx/vp8/common',
             'source/libvpx/vp8/decoder',