| Message ID | 20171001225529.9288-1-jamrial@gmail.com |
|---|---|
| State | New |
| Headers | show |
2017-10-02 0:55 GMT+02:00 James Almer <jamrial@gmail.com>: > 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. This makes it much more difficult to request backtrace etc. from users. A similar patch was rejected a few years ago. Carl Eugen
On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote: > 2017-10-02 0:55 GMT+02:00 James Almer <jamrial@gmail.com>: >> 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. > > This makes it much more difficult to request backtrace etc. > from users. How so? The installed binaries are always stripped (unless configured with --disable-stripping), with or without this patch. > > A similar patch was rejected a few years ago. > > Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
2017-10-02 1:20 GMT+02:00 James Almer <jamrial@gmail.com>: > On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote: >> 2017-10-02 0:55 GMT+02:00 James Almer <jamrial@gmail.com>: >>> 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. >> >> This makes it much more difficult to request backtrace etc. >> from users. > > How so? The installed binaries are always stripped (unless configured > with --disable-stripping), with or without this patch. We currently simply ask for "ffmpeg_g" output, even a user who has no idea about debugging either has this executable or not. Carl Eugen
On 10/1/2017 8:22 PM, Carl Eugen Hoyos wrote: > 2017-10-02 1:20 GMT+02:00 James Almer <jamrial@gmail.com>: >> On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote: >>> 2017-10-02 0:55 GMT+02:00 James Almer <jamrial@gmail.com>: >>>> 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. >>> >>> This makes it much more difficult to request backtrace etc. >>> from users. >> >> How so? The installed binaries are always stripped (unless configured >> with --disable-stripping), with or without this patch. > > We currently simply ask for "ffmpeg_g" output, even a user > who has no idea about debugging either has this executable > or not. > > Carl Eugen Then we start asking for ffmpeg output. We always request testing and backtraces using git head, and after this patch that will always be an unstripped binary, so I don't get how this is an issue.
2017-10-02 1:27 GMT+02:00 James Almer <jamrial@gmail.com>: > On 10/1/2017 8:22 PM, Carl Eugen Hoyos wrote: >> 2017-10-02 1:20 GMT+02:00 James Almer <jamrial@gmail.com>: >>> On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote: >>>> 2017-10-02 0:55 GMT+02:00 James Almer <jamrial@gmail.com>: >>>>> 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. >>>> >>>> This makes it much more difficult to request backtrace etc. >>>> from users. >>> >>> How so? The installed binaries are always stripped (unless configured >>> with --disable-stripping), with or without this patch. >> >> We currently simply ask for "ffmpeg_g" output, even a user >> who has no idea about debugging either has this executable >> or not. > > Then we start asking for ffmpeg output. We always request testing and > backtraces using git head, and after this patch that will always be an > unstripped binary, so I don't get how this is an issue. External packagers provide current binaries for all major operating systems, so I don't understand how asking current git head is related to asking debug information. Carl Eugen
On 10/1/2017 8:31 PM, Carl Eugen Hoyos wrote: > 2017-10-02 1:27 GMT+02:00 James Almer <jamrial@gmail.com>: >> On 10/1/2017 8:22 PM, Carl Eugen Hoyos wrote: >>> 2017-10-02 1:20 GMT+02:00 James Almer <jamrial@gmail.com>: >>>> On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote: >>>>> 2017-10-02 0:55 GMT+02:00 James Almer <jamrial@gmail.com>: >>>>>> 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. >>>>> >>>>> This makes it much more difficult to request backtrace etc. >>>>> from users. >>>> >>>> How so? The installed binaries are always stripped (unless configured >>>> with --disable-stripping), with or without this patch. >>> >>> We currently simply ask for "ffmpeg_g" output, even a user >>> who has no idea about debugging either has this executable >>> or not. >> >> Then we start asking for ffmpeg output. We always request testing and >> backtraces using git head, and after this patch that will always be an >> unstripped binary, so I don't get how this is an issue. > > External packagers provide current binaries for all major operating > systems, so I don't understand how asking current git head is > related to asking debug information. I'm honestly very confused. You do understand that the point of this patch is to avoid a duplicate binary on the build folder and nothing else, right? Installation is not affected. make install will behave exactly the same after this patch as it had before, and that's what external packagers package.
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@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 [...]
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@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.
On Mon, 2 Oct 2017 21:34:18 +0200 Michael Niedermayer <michael@niedermayer.cc> 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@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 Uh, doing stripping on installing is pretty common. You know what I find confusing? That it's literally impossible to use a debugger on FFmpeg. There are a bunch of obscure flags which actually stop the damn build script from stripping the libs and which bring down the optimization level, but even then the forced DCE requirement fucks with debugging.
On 10/3/2017 5:18 AM, wm4 wrote: > On Mon, 2 Oct 2017 21:34:18 +0200 > Michael Niedermayer <michael@niedermayer.cc> 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@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 > > Uh, doing stripping on installing is pretty common. > > You know what I find confusing? That it's literally impossible to use a > debugger on FFmpeg. There are a bunch of obscure flags which actually > stop the damn build script from stripping the libs and which bring down > the optimization level, but even then the forced DCE requirement fucks > with debugging. This has nothing to do with the patch and it's a discussion for another thread. I'd like to focus specifically on the patch and its effects, as I'm still trying to understand why two people say it would confuse users or lead to problems.
On Tue, 3 Oct 2017 10:23:08 -0300 James Almer <jamrial@gmail.com> wrote: > On 10/3/2017 5:18 AM, wm4 wrote: > > On Mon, 2 Oct 2017 21:34:18 +0200 > > Michael Niedermayer <michael@niedermayer.cc> 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@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 > > > > Uh, doing stripping on installing is pretty common. > > > > You know what I find confusing? That it's literally impossible to use a > > debugger on FFmpeg. There are a bunch of obscure flags which actually > > stop the damn build script from stripping the libs and which bring down > > the optimization level, but even then the forced DCE requirement fucks > > with debugging. > > This has nothing to do with the patch and it's a discussion for another > thread. The second part, sure. The first part not. autotools for example generates an install-strip target. AFAIK debug infos are always generated? In any case, that means it doesn't strip them in-tree. > I'd like to focus specifically on the patch and its effects, as I'm > still trying to understand why two people say it would confuse users or > lead to problems. At this point I think Michael is going to argue any change in behavior will be "confusing". With that attitude you can't fix anything.
On 10/3/2017 10:27 AM, wm4 wrote: > On Tue, 3 Oct 2017 10:23:08 -0300 > James Almer <jamrial@gmail.com> wrote: > >> On 10/3/2017 5:18 AM, wm4 wrote: >>> On Mon, 2 Oct 2017 21:34:18 +0200 >>> Michael Niedermayer <michael@niedermayer.cc> 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@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 >>> >>> Uh, doing stripping on installing is pretty common. >>> >>> You know what I find confusing? That it's literally impossible to use a >>> debugger on FFmpeg. There are a bunch of obscure flags which actually >>> stop the damn build script from stripping the libs and which bring down >>> the optimization level, but even then the forced DCE requirement fucks >>> with debugging. >> >> This has nothing to do with the patch and it's a discussion for another >> thread. > > The second part, sure. The first part not. autotools for example > generates an install-strip target. AFAIK debug infos are always > generated? In any case, that means it doesn't strip them in-tree. Debug symbols are always generated and stripping always happens unless --disable-debug and --disable-stripping are used respectively during configure. And yes, that's the point of this patch. Strip binaries on install and keep the build folder free of duplicates, same as we do with shared libraries. What gets installed is not affected. > >> I'd like to focus specifically on the patch and its effects, as I'm >> still trying to understand why two people say it would confuse users or >> lead to problems. > > At this point I think Michael is going to argue any change in behavior > will be "confusing". With that attitude you can't fix anything. I'd rather have him explain and not others guess or interpret, thanks.
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@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 [...]
On Tue, 3 Oct 2017 18:01:14 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote: > 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. There are lots of factors that can make ffmpeg behave different on every _invocation_. Like dynamic memory allocation or ASLR, or even the ffmpeg binary path. Should we remove all these features?
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@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.
On Tue, 3 Oct 2017, James Almer wrote: > 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@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. The only argument against this patch that I find mildly convincing is that we should do tests (fate tests) with stripped binaries in order to be able to detect bugs when stripping. But I always hated the fact that the build process is copying huge binaries. Question: why don't we use strip -o ffmpeg ffmpeg_g instead of copying first? Regards, Marton
On Tue, 3 Oct 2017 13:27:21 -0300 James Almer <jamrial@gmail.com> wrote: > 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. Sad...
On 10/3/2017 2:11 PM, wm4 wrote: > On Tue, 3 Oct 2017 13:27:21 -0300 > James Almer <jamrial@gmail.com> wrote: > >> 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. > > Sad... I don't have strong feelings for this patch. It's mean to free space (seeing some clients in fate.ffmpeg.org keep running out of it) and reduce building time. But if it ruins some people's workflow then I'm not going to fight to get it in.
diff --git a/Makefile b/Makefile index 3007da50f7..1c6bc2fbb9 100644 --- a/Makefile +++ b/Makefile @@ -96,11 +96,7 @@ include $(SRC_PATH)/doc/examples/Makefile libavcodec/utils.o libavformat/utils.o libavdevice/avdevice.o libavfilter/avfilter.o libavutil/utils.o libpostproc/postprocess.o libswresample/swresample.o libswscale/utils.o : libavutil/ffversion.h -$(PROGS): %$(PROGSSUF)$(EXESUF): %$(PROGSSUF)_g$(EXESUF) - $(CP) $< $@ - $(STRIP) $@ - -%$(PROGSSUF)_g$(EXESUF): $(FF_DEP_LIBS) +$(PROGS): %$(PROGSSUF)$(EXESUF): $(FF_DEP_LIBS) $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(OBJS-$*) $(FF_EXTRALIBS) VERSION_SH = $(SRC_PATH)/ffbuild/version.sh diff --git a/doc/examples/Makefile b/doc/examples/Makefile index ff958d33c6..c813da4505 100644 --- a/doc/examples/Makefile +++ b/doc/examples/Makefile @@ -21,16 +21,14 @@ DOC_EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac DOC_EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE) += transcoding DOC_EXAMPLES := $(DOC_EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)$(EXESUF)) -DOC_EXAMPLES_G := $(DOC_EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)_g$(EXESUF)) ALL_DOC_EXAMPLES := $(DOC_EXAMPLES) $(DOC_EXAMPLES-:%=doc/examples/%$(PROGSSUF)$(EXESUF)) -ALL_DOC_EXAMPLES_G := $(DOC_EXAMPLES_G) $(DOC_EXAMPLES-:%=doc/examples/%$(PROGSSUF)_g$(EXESUF)) PROGS += $(DOC_EXAMPLES) EXAMPLES_FILES := $(wildcard $(SRC_PATH)/doc/examples/*.c) $(SRC_PATH)/doc/examples/README EXAMPLE_MAKEFILE := $(SRC_PATH)/doc/examples/Makefile $(foreach P,$(DOC_EXAMPLES),$(eval OBJS-$(P:%$(PROGSSUF)$(EXESUF)=%) = $(P:%$(PROGSSUF)$(EXESUF)=%).o)) -$(DOC_EXAMPLES_G): %$(PROGSSUF)_g$(EXESUF): %.o +$(DOC_EXAMPLES): %$(PROGSSUF)$(EXESUF): %.o examples: $(DOC_EXAMPLES) @@ -40,8 +38,7 @@ OBJDIRS += doc/examples DOXY_INPUT += $(DOC_EXAMPLES:%$(PROGSSUF)$(EXESUF)=%.c) examplesclean: - $(RM) $(ALL_DOC_EXAMPLES) $(ALL_DOC_EXAMPLES_G) - $(RM) $(CLEANSUFFIXES:%=doc/examples/%) + $(RM) $(ALL_DOC_EXAMPLES) $(CLEANSUFFIXES:%=doc/examples/%) docclean:: examplesclean diff --git a/fftools/Makefile b/fftools/Makefile index 094f6d6265..37ff131165 100644 --- a/fftools/Makefile +++ b/fftools/Makefile @@ -8,7 +8,6 @@ PROGS += $(AVPROGS) AVBASENAMES = ffmpeg ffplay ffprobe ffserver ALLAVPROGS = $(AVBASENAMES:%=%$(PROGSSUF)$(EXESUF)) -ALLAVPROGS_G = $(AVBASENAMES:%=%$(PROGSSUF)_g$(EXESUF)) OBJS-ffmpeg += fftools/ffmpeg_opt.o fftools/ffmpeg_filter.o fftools/ffmpeg_hw.o OBJS-ffmpeg-$(CONFIG_CUVID) += fftools/ffmpeg_cuvid.o @@ -22,11 +21,11 @@ OBJS-ffserver += fftools/ffserver_config.o define DOFFTOOL OBJS-$(1)-$(CONFIG_OPENCL) += fftools/cmdutils_opencl.o OBJS-$(1) += fftools/cmdutils.o fftools/$(1).o $(OBJS-$(1)-yes) -$(1)$(PROGSSUF)_g$(EXESUF): $$(OBJS-$(1)) +$(1)$(PROGSSUF)$(EXESUF): $$(OBJS-$(1)) $$(OBJS-$(1)): | fftools $$(OBJS-$(1)): CFLAGS += $(CFLAGS-$(1)) -$(1)$(PROGSSUF)_g$(EXESUF): LDFLAGS += $(LDFLAGS-$(1)) -$(1)$(PROGSSUF)_g$(EXESUF): FF_EXTRALIBS += $(EXTRALIBS-$(1)) +$(1)$(PROGSSUF)$(EXESUF): LDFLAGS += $(LDFLAGS-$(1)) +$(1)$(PROGSSUF)$(EXESUF): FF_EXTRALIBS += $(EXTRALIBS-$(1)) -include $$(OBJS-$(1):.o=.d) endef @@ -47,6 +46,7 @@ install-progs-$(CONFIG_SHARED): install-libs install-progs: install-progs-yes $(AVPROGS) $(Q)mkdir -p "$(BINDIR)" $(INSTALL) -c -m 755 $(AVPROGS) "$(BINDIR)" + $(STRIP) $(addprefix "$(BINDIR)/", $(AVPROGS)) uninstall: uninstall-progs @@ -54,4 +54,4 @@ uninstall-progs: $(RM) $(addprefix "$(BINDIR)/", $(ALLAVPROGS)) clean:: - $(RM) $(ALLAVPROGS) $(ALLAVPROGS_G) $(CLEANSUFFIXES:%=fftools/%) + $(RM) $(ALLAVPROGS) $(CLEANSUFFIXES:%=fftools/%)
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@gmail.com> --- FATE slots will love this, especially those running on disk space deprived VMs. Makefile | 6 +----- doc/examples/Makefile | 7 ++----- fftools/Makefile | 10 +++++----- 3 files changed, 8 insertions(+), 15 deletions(-)