Re: AC_PROG_CC not working

[Morten Eriksen]

Akim Demaille <address@hidden> writes:

> Really, giving a list of compilers seems bad to me.  It should be
> the same list for everybody, i.e., let's fix the Autoconf builtin
> list if its wrong, but let's not go for various flavors of
> configure.

A few days ago I would have agreed with you on this point -- but now
I'm not so sure anymore.

The particular challenge I just bumped into is how to let Autoconf
configure know about a "self-made compiler", in the sense that I have
written a wrapper script around the MSVC++ cl.exe compiler (to let it
behave properly when run from the makefiles generated by Automake).

This wrapper is a shell script residing in some source directory of my
package, and may be viewed as a separate compiler existing only for
this project. Adding the name of my wrapper script to the beginning of
the standard list of compilers and calling AC_PROG_CC with this as an
argument seemed like the perfect way to integrate the script. But
alas, that was not to be, due to the buggy nature of this feature of
AC_PROG_CC.

So, if fixing the AC_PROG_CC bug is pointless because you think it is
wrong policy for AC_PROG_CC to take this argument, I see 2 other
options for my task at hand:

        1) notify in the INSTALL file about needing to pass on
           CC=[path/wrapperscript] when building with MSVC++. Simple
           enough, but it doesn't seem like good policy to me to "push
           complexity" on to the user.

        2) lobby to get my MSVC++ cl.exe wrapper script shipped as a
           standard part of either the Autoconf or the Automake
           distribution (and add the name of it to the list of
           compilers AC_PROG_CC looks for).

Eventually I hope to go for option 2), but this doesn't seem like
something which would go into the next version of Autoconf or
Automake, at least (it need to be properly tested, robustified, etc
etc). And I need it _now_, of course.

Regards,
Morten