Re: [PATCH] Simplify _AC_PROG_CC_G

[Morten Eriksen]

Alexandre Oliva <address@hidden> writes:

> The problem is that some compilers (GCC without GNU as on HP-UX, for
> example) will accept `-g', print a warning message and proceed to
> compilation, so the exit status is not enough.

Just in case I forgot to mention this: note that the current code in
_AC_PROG_CC_G and _AC_PROG_CXX_G doesn't even check the compiler exit
status -- only the exit status for the grep.

> On the other hand, other compilers will print a Copyright statement
> before doing anything else.

Do people here know any compilers besides Microsoft VisualC(++) which
does this?

If not, I don't think we need to worry about it. MSVC++'s cl.exe
differs so much from any UNIX/Linux compilers that it needs a wrapper
to be functional enough to be of any use.

A few of the things I've discovered while I've been trying to beat
cl.exe into submission over the last few days:

        * cl.exe writes "informational" output (copyright messages,
          echoing input filenames, general "Compiling this-and-that"
          messages, ...) on _either_ stdout or stderr

        * library paths need to be specified as /LIBPATH, not -L

        * mixing "-"-prefix options with "/"-prefix options doesn't
          work (which is more of a PITA than it sounds when trying to
          use cl.exe under Autoconf/Automake/Libtool-generated
          configure & build processes)

        * cl.exe has a different option for naming executables ("/Fe")
          than for naming object files ("/Fo")

        * cl.exe doesn't understand that .cxx is an extension for C++
          files

And the obvious but still painful:

        * it doesn't work with Cygwin-style filenames
          (i.e. /home/code/mysource.c must be translated to
          c:\home\code\mysource.c)

        * it doesn't work with Cygwin's soft- or hardlinks

And it has also uncovered a bunch of bugs in Autoconf, Automake and
Libtool, which is why I've been throwing around more-or-less
well thought out patches over the last week or so.  :^}

All the cl.exe-issues above are easily solved with a wrapper script,
though, and I've written one which I intend to eventually submit for
Autoconf (or Automake) inclusion.

(Now, if just the Libtool "architecture" didn't suck rocks through a
garden hose, I'd have a complete toolchain with MSVC++ and Cygwin from
code checkout to build to install.)

> Which means Morten's change is a step in the right direction.

Yay!  ;^)


BTW, I tend to feel that _defaulting_ to using "-g" is a mistake. As
it is now, authors of configure scripts needs to play silly tricks
with CFLAGS and/or CXXFLAGS and/or CPPFLAGS to _remove_ the "-g" flag
(for slim builds or debug builds, for instance), instead of being able
to control in a clean way when to instruct the compiler to include
debug information in the object files.

Is changing this default completely out of the question?  I can't see
that it would /break/ existing packages?

Regards,
Morten