[FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

[James Almer]

On 10/3/2017 1:01 PM, Michael Niedermayer wrote:
> On Mon, Oct 02, 2017 at 05:03:51PM -0300, James Almer wrote:
>> On 10/2/2017 4:34 PM, Michael Niedermayer wrote:
>>> On Sun, Oct 01, 2017 at 07:55:29PM -0300, James Almer wrote:
>>>> Do it during install instead, like with the libraries.
>>>>
>>>> There's no benefit making a stripped copy of the CLI tools in the
>>>> build folder. Doing it during install saves build time and storage
>>>> space.
>>>>
>>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>>
>>> Iam not sure this is a good idea
>>>
>>> the build binaries and installed binaries would differ, thats bound
>>> to lead to some confusion and problems
>>
>> What kind of confusion will removing "ffmpeg_g" from the build folder
>> bring? It's never installed, and what does get installed by "make
>> install" will not change with this patch in form or name.
>> This patch does for the binaries the same thing we're doing for the
>> libraries: Strip during install, instead of making a stripped duplicate
>> in the build folder.
> 
> The ffmpeg in the build folder will be a different binary than the
> one installed, they will look the same from the output, same
> configure flags and so on.
> But because they are different binaries they can and will behave
> differently. Bugs in the past occuring with ffmpeg did sometimes not
> reproduce with ffmpeg_g. But if one talked about "ffmpeg" or "ffmpeg_g"
> together with its command line output which contains revission and
> build flags it was clear what version was used.

> With this change its indistingishable if a "ffmpeg" is stripped or non
> stripped the printed build flags will no longer provide this
> information together with the excuatble name

If the build flags have "--disable-stripping", then "ffmpeg" will not be
stripped, regardless of this being the build folder or an installation
target. So, in short, you're arguing that in builds with stripping
enabled, ffmpeg in the build folder being different than the one in the
install folder will make getting users to provide useful reports harder?

I don't really agree with this, seeing almost every other project out
there does pretty much what this patch is trying to achieve and don't
seem to have issues handling bug reports, but if both you and Carl
consider this behavior as important for the sake of bug reporting and
nobody else chimes in in favor, then I'll withdraw this patch.