make 'ASMFLAGS' behavior similar to 'CFLAGS' and 'CXXFLAGS' variables

[sav_ix at ukr.net]

Thank you for answer, Marc,


--- Оригінальне повідомлення ---
Від кого: "Marc Glisse" <marc.glisse at inria.fr>
Дата: 1 лютого 2018, 12:07:17


> It is too bad yasm doesn't ignore '-c', using automake's CCAS support (as 
> suggested in tasks.html) might have worked otherwise (not sure).

Just in case, the only warnings, which yasm write to stderr are:
===============================================================
tmp-add_n.s:90: warning: .type pseudo-op used outside of .def/.endef; ignored
tmp-add_n.s:113: warning: directive `.size' not recognized
tmp-add_n.s:117: warning: .type pseudo-op used outside of .def/.endef; ignored
tmp-add_n.s:276: warning: directive `.size' not recognized
tmp-sub_n.s:90: warning: .type pseudo-op used outside of .def/.endef; ignored
tmp-sub_n.s:113: warning: directive `.size' not recognized

<snip>

tmp-addlsh_n.s:107: warning: .type pseudo-op used outside of .def/.endef; ignored
tmp-addlsh_n.s:246: warning: directive `.size' not recognized
tmp-rsblsh_n.s:107: warning: .type pseudo-op used outside of .def/.endef; ignored
tmp-rsblsh_n.s:246: warning: directive `.size' not recognized
===============================================================

Fortunately it's not too much of them (136 total for builds on Haswell). And they has no visible effect on GMP testsuite results, compared to  '--disable-assembly' builds.


> Still, I think it would make sense to use the name CCASFLAGS for consistency. There 
> may be a bit more to it than this patch though.

Me offered most obvious variable name. But, of course, it's up to GMP Community to decide. The main goal of that patch is to make sure, that assembler flags won't be passed to C and C++ compilers, and C and C++ flags won't be passed to assembler. So this is the only requirement, which should be considered during name selection for assembler flags variable.


> If it is the main blocking issue for a visual studio build, at least that 
> gives some motivation.

Not a blocker but rather an essential requirement. Mean GMP-MSVC binaries without assembly support won't be as interesting to Windows GMP Users, as full-featured GMP-mingw-w64 binaries.
Merging this PR to trunk would allow to decrease size of current patches to GMP build system for builds using MSVC by ~80%. Though merging some of the rest 20% 
may require more effort.


Best,

Alexander