Loren Merritt <[email protected]> writes: > On Wed, 8 Aug 2012, Mns Rullgrd wrote: >> Diego Biurrun <[email protected]> writes: >> >>> libavcodec/x86/Makefile | 6 +++--- >>> libavcodec/x86/{dsputil_yasm.asm => dsputil.asm} | 0 >>> .../x86/{dsputilenc_yasm.asm => dsputilenc.asm} | 0 >>> libavcodec/x86/{vc1dsp_yasm.asm => vc1dsp.asm} | 0 >>> 4 files changed, 3 insertions(+), 3 deletions(-) >>> rename libavcodec/x86/{dsputil_yasm.asm => dsputil.asm} (100%) >>> rename libavcodec/x86/{dsputilenc_yasm.asm => dsputilenc.asm} (100%) >>> rename libavcodec/x86/{vc1dsp_yasm.asm => vc1dsp.asm} (100%) >> >> Makes sense. _yasm doesn't convey any information not already given by >> the .asm suffix, given that all the x86 .asm files use yasm syntax. > > Same for _mmx.
In many of our cases, yes. More generally, _mmx at least says *something* that the rest of the filename does not. > Do we have a standard for what to do when we have both a dsputil.c and a > dsputil.asm, where the .o's would collide if we gave both their natural > basename? For ARM we use foo_init.c, foo.S, foo_armv6.S, etc. That makes sense there since the .c files never contain any actual code. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
