Re: /lib/cpp not found in c-mode

["Eli Zaretskii" <eliz@gnu.org>]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Fri, 6 May 2005 06:51:38 +0200
> Cc: emacs-devel@gnu.org
> 
> gcc -E can expand the macros just fine, it just needs the same input  
> (-I -D and -U) as gcc got when creating the executable.  As others  
> pointed out, it is impractical to set this up if you are working on  
> several different projects at once.

It is not impractical, since I actually do this in practice.  One way
to overcome the difficulties is to use the command history features
offered by Emacs.

Also, I really doubt that many people work ``on several different
projects at once'', literally.  I think it's an exaggeration, and that
even if someone works on several projects, they don't switch from one
project to another every minute, at least not in most cases, and
neither do they need to use c-macro-expand all the time (see below).

> Personally I don't see the need for expanding macros.  One of the  
> reasons I use them in the first place is to hide details I don't need  
> to see.  Expanding them while editing seems a strange thing to do.

When you write your code, you don't need that.  But when you need to
understand some compiler message or obscure bug in code someone else
wrote, it is sometimes hard to get along without this feature.  A case
in point is this message that GCC would once output while compiling
regex.c:

    regex.c:5179: warning: comparison is always true due to limited range of data type

The offending line was:

		    if (RE_TRANSLATE (translate, *d) != *p++)

Let me know how much time it takes you to figure out what is the
problem without expanding the macros in this line with something like
the feature we are discussing ;-)  (It took me about 5 seconds after I
expanded them.)

Granted, this is not the most important feature for C programming, but
I wouldn't say that ``I don't see the need for expanding macros''.  So
let's keep things in perspective here, okay?