On Sat, 15 Oct 2016, Diego Biurrun wrote:

On Fri, Oct 14, 2016 at 10:29:58AM +0300, Martin Storsjö wrote:
On Fri, 14 Oct 2016, Diego Biurrun wrote:
>--- a/configure
>+++ b/configure
>@@ -261,7 +261,8 @@ Toolchain options:
>  --toolchain=NAME         set tool defaults according to NAME
>  --nm=NM                  use nm tool
>  --ar=AR                  use archive tool AR [$ar_default]
>-  --as=AS                  use assembler AS [$as_default]
>+  --as=AS                  use integrated assembler AS [$as_default]
>+  --asm=ASM                use standalone assembler ASM [$asm_default]
>  --cc=CC                  use C compiler CC [$cc_default]
>  --objcc=OCC              use ObjC compiler OCC [$cc_default]
>  --dep-cc=DEPCC           use dependency generator DEPCC [$cc_default]

Eh, how is AS integrated in any way, except the fact that it often is used
from the same binutils set as the rest of the toolchain?

Integrated in the sense that it is invoked as part of the compiler invocation
and not called directly by the build system.

It sounds like you have it the wrong way around, although I guess you mean the right thing.

Whatever we set here, is called directly by the build system. See the COMPILE_S rule in Makefile; this creates a rule that calls $(AS) directly.

In many of our cases, our $(AS) will be some gcc-like frontend though, instead of the plain 'as' binary from binutils, since we rely on a C preprocessor (our sources are .S instead of .s). But in some cases, it can be a script frontend that runs cpp+assembler as well. The term "integrated assembler" sounds weird to use as name for a tool that invokes a preprocessor and assembler.

As for a better suggestion for naming, I don't know. x86-asm vs other-asm sounds strange. (We mostly use .S asm for arm and aarch64, but we have got one single file for ppc as well. Technically one could use .S for x86 as well, if one wanted to write x86 asm using the AT&T syntax and disregard all of x86inc.)

// Martin
libav-devel mailing list

Reply via email to