skufog / libyuv

Automatically exported from code.google.com/p/libyuv
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

libyuv.lib output file path changed #231

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. used project libjingle rev. 320 that includes thirdparty libyuv
2. libjingle revision update from 310->320
3. Include change of libyuv revision from 590->682

What is the expected output? What do you see instead?
I expected that the libyuv.lib file is stored under the path Debug/lib
but it is stored in Debug.

What version of the product are you using? On what operating system?
libyuv 682
windows 7

Please provide any additional information below.

used program:  Visual Studio 2010

libyuv.vcproj

Version: 590
    <TargetPath>$(OutDir)lib\$(ProjectName)$(TargetExt)</TargetPath>

Version: 682
    <TargetPath>$(OutDir)\$(ProjectName)$(TargetExt)</TargetPath>

Original issue reported on code.google.com by berthold...@googlemail.com on 17 May 2013 at 4:23

GoogleCodeExporter commented 9 years ago
Hi, Thanks for the report.
Assuming you use gyp to build the .lib I think the change you're experiencing 
is due to DEPS referring to new chromium build rules and/or depot tools.
On linux I observed the libyuv.a files became thin due to build changes, and 
made the gyp force 'fat' libs.
If the old location is important to you, you could try reverting libyuv's DEPS 
file to the old version.  The move forward was for the benefit of llvm, which 
you shouldn't care about on Windows.

Original comment by fbarch...@chromium.org on 17 May 2013 at 6:21

GoogleCodeExporter commented 9 years ago
In r701 I've rolled to chromium deps of r202548 for the latest build rules.
This should be consistent with chrome and webrtc target locations.

Original comment by fbarch...@google.com on 28 May 2013 at 5:07