https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85777
--- Comment #10 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Jakub Jelinek from comment #9)
> That is not true, automake is highly customizable, you can e.g. override
> COMPILE/LTCOMPILE variables in Makefile.am or something similar.
The issue is that what COMPILE/LTCOMPILE should contain is not specified, so
that it is impossible to write a replacement that will be guaranteed to work in
a portable way.
For instance, the following is generated:
LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
$(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
$(AM_CFLAGS) $(CFLAGS)
but the AM_V_lt variable is nowhere documented. Thus replacing
COMPILE/LTCOMPILE would require the developer to use obscure internals. I will
never do that!
Anyway, this would not be these variables that one would need to change, but
the Make rules that invoke the compiler, like:
.c.o:
$(AM_V_CC)depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`;\
$(COMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\
$(am__mv) $$depbase.Tpo $$depbase.Po
# $(AM_V_CC)source='$<' object='$@' libtool=no \
# DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
# $(AM_V_CC_no)$(COMPILE) -c -o $@ $<
But this is even worse: more internals, more code that is platform-dependent...
