/lib/cpp not found in c-mode

/lib/cpp not found in c-mode

[Stefan Monnier]

I just got the following backtrace.  Any idea what's up?
I indeed don't have /lib/cpp (this is on MacOSX) but it shouldn't prevent me
from opening a C file,


        Stefan


Debugger entered--Lisp error: (file-error "Searching for program" "no such file or directory" "/lib/cpp")
  call-process("/lib/cpp" "/Users/monnier/src/emacs/work/src/xterm.c" t nil "-dM")
  cc-create-define-alist()
  c-mode()
  set-auto-mode-0(c-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer xterm.c> "~/src/emacs/work/src/xterm.c" nil nil "~/src/emacs/work/src/xterm.c" (5067662 234881033))
  find-file-noselect("xterm.c")
  gdb-info-breakpoints-custom()
  gdb-info-breakpoints-handler()
  gdb-prompt("")
  gud-gdba-marker-filter("\n\x1a\x1apre-prompt\n(gdb) \n\x1a\x1aprompt\n")
  apply(gud-gdba-marker-filter "\n\x1a\x1apre-prompt\n(gdb) \n\x1a\x1aprompt\n")
  gud-marker-filter("\n\x1a\x1apre-prompt\n(gdb) \n\x1a\x1aprompt\n")
  gud-filter(#<process gud-emacs> "\n\x1a\x1apre-prompt\n(gdb) \n\x1a\x1aprompt\n")

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 01 May 2005 12:47:37 -0400
> 
> I just got the following backtrace.  Any idea what's up?
> I indeed don't have /lib/cpp (this is on MacOSX) but it shouldn't prevent me
> from opening a C file,

Not only that, it IMHO shouldn't call "/lib/cpp" unconditionally, but
rather try several possible file commands, including "gcc -E", "cpp"
(without leading directories), etc.

/lib/cpp not found in c-mode

[Nick Roberts]

 > I just got the following backtrace.  Any idea what's up?
 > I indeed don't have /lib/cpp (this is on MacOSX) but it shouldn't prevent me
 > from opening a C file,

In this case, how does your system find c-macro-preprocessor?. Do you have
/usr/ccs/lib/cpp? If so, oes it support the -dM switch option (or equivalent)?

Nick


(defcustom c-macro-preprocessor
  ;; Cannot rely on standard directory on MS-DOS to find CPP.  In
  ;; fact, cannot rely on having cpp.exe, either, in latest GCC
  ;; versions.
  (cond ((eq system-type 'ms-dos) "gcc -E -C -o - -")
	;; Solaris has it in an unusual place.
	((and (string-match "^[^-]*-[^-]*-\\(solaris\\|sunos5\\)"
			    system-configuration)
	      (file-exists-p "/opt/SUNWspro/SC3.0.1/bin/acomp"))
	 "/opt/SUNWspro/SC3.0.1/bin/acomp -C -E")
        ((file-exists-p "/usr/ccs/lib/cpp") "/usr/ccs/lib/cpp -C")
	(t "/lib/cpp -C"))
  "The preprocessor used by the cmacexp package.

If you change this, be sure to preserve the `-C' (don't strip comments)
option, or to set an equivalent one."
  :type 'string
  :group 'c-macro)

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

[Nick Roberts]

 > Not only that, it IMHO shouldn't call "/lib/cpp" unconditionally, but
 > rather try several possible file commands, including "gcc -E", "cpp"
 > (without leading directories), etc.

Hopefully, it fails gracefully now. I use "gcc -E -dM -" now to generate a
define list.  Have you any ideas to make it more general?

Nick

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

[Jan D.]

>> I just got the following backtrace.  Any idea what's up?
>> I indeed don't have /lib/cpp (this is on MacOSX) but it shouldn't 
>> prevent me
>> from opening a C file,
>
> In this case, how does your system find c-macro-preprocessor?. Do you 
> have
> /usr/ccs/lib/cpp? If so, oes it support the -dM switch option (or 
> equivalent)?
>

On my OSX (10.3.8) it is in /usr/bin/cpp.  But isn't using cpp directly 
deprecated? I don't think gcc installs cpp by default anymore.

	Jan D.

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

[Nick Roberts]

Jan D. writes:
 > >> I just got the following backtrace.  Any idea what's up?
 > >> I indeed don't have /lib/cpp (this is on MacOSX) but it shouldn't 
 > >> prevent me
 > >> from opening a C file,
 > >
 > > In this case, how does your system find c-macro-preprocessor?. Do you 
 > > have
 > > /usr/ccs/lib/cpp? If so, oes it support the -dM switch option (or 
 > > equivalent)?
 > >
 > 
 > On my OSX (10.3.8) it is in /usr/bin/cpp.  

In that case, c-macro-preprocessor is set to "/lib/cpp -C" and c-macro-expand
doesn't work on OSX?

 > But isn't using cpp directly deprecated? I don't think gcc installs cpp by
 > default anymore.

Does c-macro-preprocessor also need updating then?

Nick

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

[Stefan Monnier]

>> Not only that, it IMHO shouldn't call "/lib/cpp" unconditionally, but
>> rather try several possible file commands, including "gcc -E", "cpp"
>> (without leading directories), etc.

> Hopefully, it fails gracefully now. I use "gcc -E -dM -" now to generate a
> define list.  Have you any ideas to make it more general?

gcc might not be available either.
And the file may not be local (it may be accessed via Tramp or jka-compr).
I.e. "fails gracefully" can't be obtained without a condition-case.

And AFAICT the result is completely unused unless you happen to also use
gud-tooltips.

You'd be better served postponing execution of such a command to the moment
when it's actually needed (i.e. when gud-tooltips are actually being used).
If the user gets an error when she uses gud-tooltips, he won't mind, but if
she gets the error about something that she won't even ever use, she has
reasons to be upset.


        Stefan

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

[Jan D.]

> Jan D. writes:
>>>> I just got the following backtrace.  Any idea what's up?
>>>> I indeed don't have /lib/cpp (this is on MacOSX) but it shouldn't
>>>> prevent me
>>>> from opening a C file,
>>>
>>> In this case, how does your system find c-macro-preprocessor?. Do you
>>> have
>>> /usr/ccs/lib/cpp? If so, oes it support the -dM switch option (or
>>> equivalent)?
>>>
>>
>> On my OSX (10.3.8) it is in /usr/bin/cpp.
>
> In that case, c-macro-preprocessor is set to "/lib/cpp -C" and 
> c-macro-expand
> doesn't work on OSX?

If c-macro-preprocessor is a recent variable I can't check because 
Emacs does not currently compile on Mac OSX 10.3.  My (a bit old) CVS 
compile does not seem to have it.

But c-macro-expand does not work:

/* Preprocessor terminated with status 127

    Messages from `/lib/cpp -C ':

/bin/bash: line 1: /lib/cpp: No such file or directory


*/

Preprocessor produced no output


	Jan D.

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

[Nick Roberts]

 > >> On my OSX (10.3.8) it is in /usr/bin/cpp.
 > >
 > > In that case, c-macro-preprocessor is set to "/lib/cpp -C" and 
 > > c-macro-expand
 > > doesn't work on OSX?
 > 
 > If c-macro-preprocessor is a recent variable I can't check because 
 > Emacs does not currently compile on Mac OSX 10.3.  My (a bit old) CVS 
 > compile does not seem to have it.

c-macro-expand and c-macro-preprocessor have been around for quite a
while. c-macro-expand is an interactive autoloaded Lisp function in cmacexp.el
that can be invoked in C mode with C-c C-e or from the menu-bar.  Apparently
this file is not part of cc-mode so perhaps its not being maintained.
c-macro-expand seems quite useful so I'm kind of surprised that, as a C
specialist, you're don't use it/not familiar with it.

 > But c-macro-expand does not work:

If we added the line below to c-macro-preprocessor would it work then for Mac
OSX?

Nick


(defcustom c-macro-preprocessor
  ;; Cannot rely on standard directory on MS-DOS to find CPP.  In
  ;; fact, cannot rely on having cpp.exe, either, in latest GCC
  ;; versions.
  (cond ((eq system-type 'ms-dos) "gcc -E -C -o - -")
	;; Solaris has it in an unusual place.
	((and (string-match "^[^-]*-[^-]*-\\(solaris\\|sunos5\\)"
			    system-configuration)
	      (file-exists-p "/opt/SUNWspro/SC3.0.1/bin/acomp"))
	 "/opt/SUNWspro/SC3.0.1/bin/acomp -C -E")
        ((file-exists-p "/usr/ccs/lib/cpp") "/usr/ccs/lib/cpp -C")
+	((eq system-type 'darwin) "cpp -C")
	(t "/lib/cpp -C"))
  "The preprocessor used by the cmacexp package.

If you change this, be sure to preserve the `-C' (don't strip comments)
option, or to set an equivalent one."
  :type 'string
  :group 'c-macro)

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

[Nick Roberts]

Stefan Monnier writes:
 > >> Not only that, it IMHO shouldn't call "/lib/cpp" unconditionally, but
 > >> rather try several possible file commands, including "gcc -E", "cpp"
 > >> (without leading directories), etc.
 > 
 > > Hopefully, it fails gracefully now. I use "gcc -E -dM -" now to generate a
 > > define list.  Have you any ideas to make it more general?
 > 
 > gcc might not be available either.
 > And the file may not be local (it may be accessed via Tramp or jka-compr).
 > I.e. "fails gracefully" can't be obtained without a condition-case.

It uses call-process through a shell now and discards standard error so if
gcc is not available no define list is generated. How would condition-case
help?

 > And AFAICT the result is completely unused unless you happen to also use
 > gud-tooltips.

Thats currently true. However, tooltips could be used to display the #define
directives when just source browsing i.e. they don't need GUD.

 > You'd be better served postponing execution of such a command to the moment
 > when it's actually needed (i.e. when gud-tooltips are actually being used).

I could do it at the same time that I check whether existing or new buffers
require gud-minor-mode to be set.

 > If the user gets an error when she uses gud-tooltips, he won't mind, but if
 > she gets the error about something that she won't even ever use, she has
 > reasons to be upset.

I see no reason now for an error to occur but, if we only use this feature
with GUD, it clearly is more efficient to only activate for buffers that are
part of the session.

Nick

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

[Stefan Monnier]

> c-macro-expand and c-macro-preprocessor have been around for quite
> a while. c-macro-expand is an interactive autoloaded Lisp function in
> cmacexp.el that can be invoked in C mode with C-c C-e or from the
> menu-bar.  Apparently this file is not part of cc-mode so perhaps its not
> being maintained.  c-macro-expand seems quite useful so I'm kind of
> surprised that, as a C specialist, you're don't use it/not familiar
> with it.

Don't know about others, but the reason why I don't use c-macro-expand is
because it basically can't work right without parsing my Makefile(s) to know
which include dirs should be used.  And since it doesn't do that, I've found
it of little use.


        Stefan

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

[Nick Roberts]

 > Don't know about others, but the reason why I don't use c-macro-expand is
 > because it basically can't work right without parsing my Makefile(s) to know
 > which include dirs should be used.  And since it doesn't do that, I've found
 > it of little use.

OK. I see now. For Emacs, the source seems to have the same flags. So, in
that case, I guess you could do something like:

(setq c-macro-cppflags "-Demacs -DHAVE_CONFIG_H -DUSE_LUCID  -I. -I/home/nick/emacs/src -D_BSD_SOURCE -I/usr/X11R6/include")

Nick

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

[Jan D.]

>>> In that case, c-macro-preprocessor is set to "/lib/cpp -C" and
>>> c-macro-expand
>>> doesn't work on OSX?
>>
>> If c-macro-preprocessor is a recent variable I can't check because
>> Emacs does not currently compile on Mac OSX 10.3.  My (a bit old) CVS
>> compile does not seem to have it.
>
> c-macro-expand and c-macro-preprocessor have been around for quite a
> while. c-macro-expand is an interactive autoloaded Lisp function in 
> cmacexp.el
> that can be invoked in C mode with C-c C-e or from the menu-bar.  
> Apparently
> this file is not part of cc-mode so perhaps its not being maintained.
> c-macro-expand seems quite useful so I'm kind of surprised that, as a C
> specialist, you're don't use it/not familiar with it.

I must have misspelled the name when looking for it.  I've seen the 
macro expand region menu item in the C menu, but actually never had any 
use for it.

>
>> But c-macro-expand does not work:
>
> If we added the line below to c-macro-preprocessor would it work then 
> for Mac
> OSX?

Yes it would.

	Jan D.


> Nick
>
>
> (defcustom c-macro-preprocessor
>   ;; Cannot rely on standard directory on MS-DOS to find CPP.  In
>   ;; fact, cannot rely on having cpp.exe, either, in latest GCC
>   ;; versions.
>   (cond ((eq system-type 'ms-dos) "gcc -E -C -o - -")
> 	;; Solaris has it in an unusual place.
> 	((and (string-match "^[^-]*-[^-]*-\\(solaris\\|sunos5\\)"
> 			    system-configuration)
> 	      (file-exists-p "/opt/SUNWspro/SC3.0.1/bin/acomp"))
> 	 "/opt/SUNWspro/SC3.0.1/bin/acomp -C -E")
>         ((file-exists-p "/usr/ccs/lib/cpp") "/usr/ccs/lib/cpp -C")
> +	((eq system-type 'darwin) "cpp -C")
> 	(t "/lib/cpp -C"))
>   "The preprocessor used by the cmacexp package.
>
> If you change this, be sure to preserve the `-C' (don't strip comments)
> option, or to set an equivalent one."
>   :type 'string
>   :group 'c-macro)

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

[Stefan Monnier]

>> Don't know about others, but the reason why I don't use c-macro-expand is
>> because it basically can't work right without parsing my Makefile(s) to know
>> which include dirs should be used.  And since it doesn't do that, I've found
>> it of little use.

> OK. I see now. For Emacs, the source seems to have the same flags. So, in
> that case, I guess you could do something like:

> (setq c-macro-cppflags "-Demacs -DHAVE_CONFIG_H -DUSE_LUCID  -I. -I/home/nick/emacs/src -D_BSD_SOURCE -I/usr/X11R6/include")

Except that Emacs is not the only project I work on that uses the
C language.


        Stefan

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

[Richard Stallman]

    Don't know about others, but the reason why I don't use c-macro-expand is
    because it basically can't work right without parsing my Makefile(s) to know
    which include dirs should be used.  And since it doesn't do that, I've found
    it of little use.

What information would it need in order to DTRT for you?

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

[Stefan Monnier]

>     Don't know about others, but the reason why I don't use c-macro-expand
>     is because it basically can't work right without parsing my
>     Makefile(s) to know which include dirs should be used.  And since it
>     doesn't do that, I've found it of little use.

> What information would it need in order to DTRT for you?

I'm not sure what you didn't understand, so I'll just rephrase it:
in order for the output of cpp to be useful, you need to make sure that all
the #include do find the corresponding header file (also it'd be better if
the various predefined macros, via -D or built-in into the compiler were
handled correctly).  This info is in general only available by parsing the
Makefile (or equivalent for people who use other tools).

Of course I can also manually take the relevant info from the Makefile and
put it into c-macro-cppflags, but doing that for each and every project
I work on is just too much trouble for me to even try it.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 02 May 2005 18:16:33 -0400
> Cc: "Jan D." <jan.h.d@swipnet.se>, emacs-devel@gnu.org
> 
> Don't know about others, but the reason why I don't use c-macro-expand is
> because it basically can't work right without parsing my Makefile(s) to know
> which include dirs should be used.

??? Isn't it a simple matter of looking at the Makefile and passing
the relevant switches to the preprocessor?  If the Makefile is too
complex to figure out the switches, I usually invoke "make foo.o" to
see what switches it uses, then copy them into the c-macro-expand's
prompt for arguments.

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

[Magnus Henoch]

Nick Roberts <nickrob@snap.net.nz> writes:

> If we added the line below to c-macro-preprocessor would it work then for Mac
> OSX?

This change is needed for NetBSD as well (and possibly other BSDs).

Magnus

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

[Stefan Monnier]

>> Don't know about others, but the reason why I don't use c-macro-expand is
>> because it basically can't work right without parsing my Makefile(s) to
>> know which include dirs should be used.

> ??? Isn't it a simple matter of looking at the Makefile and passing
> the relevant switches to the preprocessor?  If the Makefile is too
> complex to figure out the switches, I usually invoke "make foo.o" to
> see what switches it uses, then copy them into the c-macro-expand's
> prompt for arguments.

Seems like much too much trouble compared to the functionality offered,


        Stefan

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

[Nick Roberts]

 > > OK. I see now. For Emacs, the source seems to have the same flags. So, in
 > > that case, I guess you could do something like:
 > 
 > > (setq c-macro-cppflags "-Demacs -DHAVE_CONFIG_H -DUSE_LUCID  -I. -I/home/nick/emacs/src -D_BSD_SOURCE -I/usr/X11R6/include")
 > 
 > Except that Emacs is not the only project I work on that uses the
 > C language.

Thats why I said "in the case of Emacs": I was just pointing out
c-macro-cppflags as an option.

Nick

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

[Stefan Monnier]

> Don't you use the same set of include directories for all, or nearly
> all, of the C files in a directory?

Yes, of course.  The problem is between different directories (different
copies of the same project, or different projects).

> As long as that is the case, it should not be terribly hard to specify
> that info for the whole directory, and thus make c-macro-expand work.

Could be, although I don't know of any mechanism to do that right now.


        Stefan

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

[Nick Roberts]

 > You'd be better served postponing execution of such a command to the moment
 > when it's actually needed (i.e. when gud-tooltips are actually being used).
 > If the user gets an error when she uses gud-tooltips, he won't mind, but if
 > she gets the error about something that she won't even ever use, she has
 > reasons to be upset.

I've moved it closer to this: the define lists are only generated in a debug
session. To do this only when gud-tooltips are being used means that the list
generation etc needs to be triggered when tooltip-gud-tips-p is set to t and
the local variable gdb-define-alist killed etc when it's set to nil. Perhaps
tooltip-gud-tips-p should be replaced with some kind of minor mode.

Any ideas?

Nick

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

[Josh Varner]

On 5/3/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >     Don't know about others, but the reason why I don't use c-macro-expand
> >     is because it basically can't work right without parsing my
> >     Makefile(s) to know which include dirs should be used.  And since it
> >     doesn't do that, I've found it of little use.
> 
> > What information would it need in order to DTRT for you?
> 
. . .
> Of course I can also manually take the relevant info from the Makefile and
> put it into c-macro-cppflags, but doing that for each and every project
> I work on is just too much trouble for me to even try it.
> 
Assuming you do your compiles from emacs you should have the full
command lines used to compile the sources, i.e. containing all of the
relevant -I and -D's. Could a function be used to grab this
information out of the compilation buffers and store it for use by
c-macro-expand?

If this was automated in such a way that you could have an association
between files, or groups of files and the options used by
c-macro-expand, a hook in the compilation buffer could grab that
information during each build for later use. That would give you the
flexibility without the tedium.

Josh

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

[Nick Roberts]

 > > If we added the line below to c-macro-preprocessor would it work then for
 > > Mac OSX?
 > 
 > This change is needed for NetBSD as well (and possibly other BSDs).

I've now changed the condition to:

	((memq system-type '(darwin berkeley-unix)) "gcc -E -C -")

If system-type is not berkeley-unix for you, please tell me what it is.

Nick

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 03 May 2005 16:23:40 -0400
> Cc: emacs-devel@gnu.org
> 
> > ??? Isn't it a simple matter of looking at the Makefile and passing
> > the relevant switches to the preprocessor?  If the Makefile is too
> > complex to figure out the switches, I usually invoke "make foo.o" to
> > see what switches it uses, then copy them into the c-macro-expand's
> > prompt for arguments.
> 
> Seems like much too much trouble compared to the functionality offered,

Not when you really need it, like when a complicated macro causes some
bug or compiler message you cannot figure out.

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

[Richard Stallman]

    > As long as that is the case, it should not be terribly hard to specify
    > that info for the whole directory, and thus make c-macro-expand work.

    Could be, although I don't know of any mechanism to do that right now.

I could imagine putting a special file in the directory, or a hint
specifically for Emacs in Makefile in the directory.

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

[Nick Roberts]

 > > > ??? Isn't it a simple matter of looking at the Makefile and passing
 > > > the relevant switches to the preprocessor?  If the Makefile is too
 > > > complex to figure out the switches, I usually invoke "make foo.o" to
 > > > see what switches it uses, then copy them into the c-macro-expand's
 > > > prompt for arguments.
 > > 
 > > Seems like much too much trouble compared to the functionality offered,
 > 
 > Not when you really need it, like when a complicated macro causes some
 > bug or compiler message you cannot figure out.

As I'm sure you know, GCC (3.1 onwards) provides macro information if you
specify the options -gdwarf-2 and -g3. So while debugging you can
expand a macro with

/* -*- compile-command: "cc -g3 -o myprog myprog.c myprint.o -lm"; -*- */

#include <stdlib.h>
#include <math.h>

(gdb) macro expand M_PI
expands to: 3.14159265358979323846
(gdb) info macro M_PI
Defined at /usr/include/math.h:311
  included at /home/nick/myprog.c:4
#define M_PI 3.14159265358979323846

If gdb can expand macros using macro information from the executable
(which requires knowledge of include paths and predefined macros), why
can't cpp (or gcc -E) ?

Nick

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

[Stefan Monnier]

> I've now changed the condition to:

> 	((memq system-type '(darwin berkeley-unix)) "gcc -E -C -")

Testing system-type strikes me as wrong (as usual).  Since it's the
penultimate entry and the last one says "/lib/cpp" we should probably just
do something more like:

 	((not (file-executable-p "/lib/cpp")) "gcc -E -C -")


-- Stefan

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

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Thu, 5 May 2005 22:58:45 +1200
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> As I'm sure you know, GCC (3.1 onwards) provides macro information if you
> specify the options -gdwarf-2 and -g3.

On GNU/Linux, perhaps, but not on all platforms supported by GCC.

> If gdb can expand macros using macro information from the executable
> (which requires knowledge of include paths and predefined macros), why
> can't cpp (or gcc -E) ?

Actually, GDB doesn't know anything about paths and predefined macros,
it simply uses the information about macros recorded by the compiler
in the DWARF-2 debug info.  That's why you need to use -g3: this tells
the compiler to record macro information.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 05 May 2005 10:17:14 -0400
> Cc: Magnus Henoch <mange@freemail.hu>, emacs-devel@gnu.org
> 
> > 	((memq system-type '(darwin berkeley-unix)) "gcc -E -C -")
> 
> Testing system-type strikes me as wrong (as usual).

Agreed.

> Since it's the penultimate entry and the last one says "/lib/cpp" we
> should probably just do something more like:
> 
>  	((not (file-executable-p "/lib/cpp")) "gcc -E -C -")

Right, but please amend this to look for cpp.exe etc. on systems that
need that (or perhaps file-executable-p should try that
automatically?).

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

[Stefan Monnier]

>> ((not (file-executable-p "/lib/cpp")) "gcc -E -C -")

> Right, but please amend this to look for cpp.exe etc. on systems that
> need that (or perhaps file-executable-p should try that
> automatically?).

Or maybe (executable-find "/lib/cpp"),


        Stefan

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

[Nick Roberts]

Stefan Monnier writes:
 > >> ((not (file-executable-p "/lib/cpp")) "gcc -E -C -")
 > 
 > > Right, but please amend this to look for cpp.exe etc. on systems that
 > > need that (or perhaps file-executable-p should try that
 > > automatically?).
 > 
 > Or maybe (executable-find "/lib/cpp"),

Since its a trivial change for someone who knows what the right change is,
could you or Eli make it please. I think my changes are more general, but
theres not much point in them being continually reviewed for correctness.

Also could you please DTRT for gdb-cpp-define-alist-program.

Thanks,

Nick

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

[Nick Roberts]

 > > If gdb can expand macros using macro information from the executable
 > > (which requires knowledge of include paths and predefined macros), why
 > > can't cpp (or gcc -E) ?
 > >
 > 
 > The information you see in gdb is all from the debug info in the  
 > executable, so it does not require knowledge of include paths and  
 > predefined macros.  The compilation of the executable does, but after  
 > that it is all in the debug info, so gdb does not care what the  
 > include paths where at the time of compilation.
 > 
 >      Jan D.

Sorry, yes you're right it doesn't care what the include paths where. But my
point is that it can expand all the macros while "gcc -E" can't. "gcc -E" is
typically given the source file as input but if it was also given the
executable, it presumably could be adapted so that it could expand all the
macros just like GDB can.

Would that not be a worthwhile thing to do?

Nick

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

[Jan D.]

>> The information you see in gdb is all from the debug info in the
>> executable, so it does not require knowledge of include paths and
>> predefined macros.  The compilation of the executable does, but after
>> that it is all in the debug info, so gdb does not care what the
>> include paths where at the time of compilation.
>>
>>      Jan D.
>>
>
> Sorry, yes you're right it doesn't care what the include paths  
> where. But my
> point is that it can expand all the macros while "gcc -E" can't.  
> "gcc -E" is
> typically given the source file as input but if it was also given the
> executable, it presumably could be adapted so that it could expand  
> all the
> macros just like GDB can.
>
> Would that not be a worthwhile thing to do?

If the executable exists already, why am I typing in the source code  
in Emacs? :-)
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.

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.

     Jan D.

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

[Eli Zaretskii]

> 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?

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

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Fri, 6 May 2005 09:02:51 +1200
> Cc: Eli Zaretskii <eliz@gnu.org>, mange@freemail.hu,
> 	emacs-devel@gnu.org
> 
> Stefan Monnier writes:
>  > >> ((not (file-executable-p "/lib/cpp")) "gcc -E -C -")
>  > 
>  > > Right, but please amend this to look for cpp.exe etc. on systems that
>  > > need that (or perhaps file-executable-p should try that
>  > > automatically?).
>  > 
>  > Or maybe (executable-find "/lib/cpp"),
> 
> Since its a trivial change for someone who knows what the right change is,
> could you or Eli make it please. I think my changes are more general, but
> theres not much point in them being continually reviewed for correctness.

Done.  I preferred to use locate-file instead of executable-find,
since the latter would load another package.

The new version is below, in case someone wants to comment.


(defcustom c-macro-preprocessor
  (cond ;; Solaris has it in an unusual place.
	((and (string-match "^[^-]*-[^-]*-\\(solaris\\|sunos5\\)"
			    system-configuration)
	      (file-exists-p "/opt/SUNWspro/SC3.0.1/bin/acomp"))
	 "/opt/SUNWspro/SC3.0.1/bin/acomp -C -E")
        ((locate-file "/usr/ccs/lib/cpp"
		      '("/") exec-suffixes 'file-executable-p)
	 "/usr/ccs/lib/cpp -C")
	((locate-file "/lib/cpp"
		      '("/") exec-suffixes 'file-executable-p)
	 "/lib/cpp -C")
	;; On some systems, we cannot rely on standard directories to
	;; find CPP.  In fact, we cannot rely on having cpp, either,
	;; in some GCC versions.
	((locate-file "cpp" exec-path exec-suffixes 'file-executable-p)
	 "cpp -C")
	(t "gcc -E -C -o - -"))
  "The preprocessor used by the cmacexp package.

If you change this, be sure to preserve the `-C' (don't strip comments)
option, or to set an equivalent one."
  :type 'string
  :group 'c-macro)

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

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Fri, 6 May 2005 09:02:51 +1200
> Cc: Eli Zaretskii <eliz@gnu.org>, mange@freemail.hu,
> 	emacs-devel@gnu.org
> 
> Also could you please DTRT for gdb-cpp-define-alist-program.

Done.  (The test for ms-dos was redundant.)

Btw, byte-compiling gdb-ui.el emits these two warnings which I think
should be taken care of:

  In gdb-info-locals-handler:
  gdb-ui.el:1944:8:Warning: function `gdb-info-locals-handler' defined multiple
      times in this file

  In gdb-invalidate-assembler:
  gdb-ui.el:2468:8:Warning: function `gdb-invalidate-assembler' defined multiple
      times in this file

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

[Nick Roberts]

 > > Also could you please DTRT for gdb-cpp-define-alist-program.
 > 
 > Done.  (The test for ms-dos was redundant.)

Thanks.

 > Btw, byte-compiling gdb-ui.el emits these two warnings which I think
 > should be taken care of:
 > 
 >   In gdb-info-locals-handler:
 >   gdb-ui.el:1944:8:Warning: function `gdb-info-locals-handler' defined
 >       multiple times in this file
 > 
 >   In gdb-invalidate-assembler:
 >   gdb-ui.el:2468:8:Warning: function `gdb-invalidate-assembler' defined
 >       multiple times in this file

The macro def-gdb-auto-updated-buffer defines a group of functions in a
standard for the different GDB-UI buffers (stack, locals etc). The two
functions above need to work slightly differently so they are defined
explicitly *after* their definition in the macro. Its a bit messy, but I don't
know how to get round it.

Nick

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

[Nick Roberts]

 > Done.  I preferred to use locate-file instead of executable-find,
 > since the latter would load another package.

Yes. locate-file seems useful enough to justify a description in the Lisp
Reference Manual. However, I don't see why it should get an entry in NEWS as
it isn't a user-visible change.

Nick

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

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 8 May 2005 14:54:14 +1200
> Cc: emacs-devel@gnu.org
> 
> Yes. locate-file seems useful enough to justify a description in the Lisp
> Reference Manual.

Agreed.  And it will be, now that it's in NEWS and not marked as
already documented.

> However, I don't see why it should get an entry in NEWS as it isn't
> a user-visible change.

??? Entries in NEWS are subdivided into several categories; one of
them is "Lisp changes in Emacs X.YZ".  locate-file is a function that
didn't exist in previous versions, so it's a Lisp-level change.
Moreover, we want Lisp programmers to know about it because it
performs its job in a way that hides system dependencies while doing
TRT.  It also was important enough to require a new primitive,
locate-file-internal.  All of these IMHO point to the fact that
locate-file should be in NEWS.

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

[Nick Roberts]

 > > However, I don't see why it should get an entry in NEWS as it isn't
 > > a user-visible change.
 > 
 > ??? Entries in NEWS are subdivided into several categories; one of
 > them is "Lisp changes in Emacs X.YZ".  locate-file is a function that
 > didn't exist in previous versions, so it's a Lisp-level change.
 > Moreover, we want Lisp programmers to know about it because it
 > performs its job in a way that hides system dependencies while doing
 > TRT.  It also was important enough to require a new primitive,
 > locate-file-internal.  All of these IMHO point to the fact that
 > locate-file should be in NEWS.

I am just trying to understand the relationship between things. Lisp changes
could refer to variables and interactive functions. Who is NEWS directed at?
Users or developers?

What you say sounds reasonable but in that case, I think the first line of
NEWS should be changed:

GNU Emacs NEWS -- history of user-visible changes.  2003-05-21
                             ^^^^^^^^^^^^
to something like say:

GNU Emacs NEWS -- history of user-visible and lisp level changes.  2003-05-21


Nick

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

[Richard Stallman]

    Yes. locate-file seems useful enough to justify a description in the Lisp
    Reference Manual.

I agree.  Would someone like to write this?

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

[Richard Stallman]

      locate-file is a function that
     > didn't exist in previous versions, so it's a Lisp-level change.
     > Moreover, we want Lisp programmers to know about it because it
     > performs its job in a way that hides system dependencies while doing
     > TRT.

That is right.

    Who is NEWS directed at?
    Users or developers?

NEWS is meant for users, not developers.  Users of Emacs often write
Lisp programs, so changes in the Emacs Lisp language features
are part of the information they need.

    GNU Emacs NEWS -- history of user-visible changes.  2003-05-21
				 ^^^^^^^^^^^^
    to something like say:

    GNU Emacs NEWS -- history of user-visible and lisp level changes.  2003-05-21

That text is correct and doesn't need change.  (However, the date
should be updated.)

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

[Stefan Monnier]

> Done.  I preferred to use locate-file instead of executable-find,
> since the latter would load another package.

Actually, looking at the definition of executable-find, I'm surprised it
doesn't use locate-file.  The patch below should fix it so that
executable-find uses the same code used by `call-process'.
The new code is nothing else than a call to locate-file and I'd argue
that Eli's change from executable-find to locate-file is a bad idea and
instead we should simply move executable-find from executable.el to
subr.el.


        Stefan


--- orig/lisp/progmodes/executable.el
+++ mod/lisp/progmodes/executable.el
@@ -165,25 +165,7 @@
 (defun executable-find (command)
   "Search for COMMAND in `exec-path' and return the absolute file name.
 Return nil if COMMAND is not found anywhere in `exec-path'."
-  (let ((list exec-path)
-	file)
-    (while list
-      (setq list
-	    (if (and (setq file (expand-file-name command (car list)))
-		     (let ((suffixes exec-suffixes)
-			   candidate)
-		       (while suffixes
-			 (setq candidate (concat file (car suffixes)))
-			 (if (and (file-executable-p candidate)
-				  (not (file-directory-p candidate)))
-			     (setq suffixes nil)
-			   (setq suffixes (cdr suffixes))
-			   (setq candidate nil)))
-		       (setq file candidate)))
-		nil
-	      (setq file nil)
-	      (cdr list))))
-    file))
+  (locate-file command exec-path exec-suffixes 1))
 
 (defun executable-chmod ()
   "This gets called after saving a file to assure that it be executable.

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

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 8 May 2005 16:59:33 +1200
> Cc: emacs-devel@gnu.org
> 
> Who is NEWS directed at?  Users or developers?

If by `developers'' you mean people who write Lisp code (as opposed to
Emacs developers), then NEWS is both for users and developers.

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

[Eli Zaretskii]

> Cc: Nick Roberts <nickrob@snap.net.nz>, mange@freemail.hu,
> 	emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 08 May 2005 13:31:20 -0400
> 
> Actually, looking at the definition of executable-find, I'm surprised it
> doesn't use locate-file.

IIRC, executable-find was in existence longe before you added
locate-file.

> The new code is nothing else than a call to locate-file and I'd argue
> that Eli's change from executable-find to locate-file is a bad idea and
> instead we should simply move executable-find from executable.el to
> subr.el.

Well, if you are going to use integer values as the last arg to
locate-file (which is deprecated usage, as the doc string says), why
not call locate-file-internal directly and save a few cycles?

Also, I think this should go into files.el, not subr.el, since
locate-file is in files.el.

Other than that, I don't mind; I think that executable-find indeed
doesn't belong in executable.el.

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

[Eli Zaretskii]

> Date: Sun, 08 May 2005 22:02:25 +0300
> From: "Eli Zaretskii" <eliz@gnu.org>
> Cc: mange@freemail.hu, emacs-devel@gnu.org
> 
> Well, if you are going to use integer values as the last arg to
> locate-file (which is deprecated usage, as the doc string says), why
> not call locate-file-internal directly and save a few cycles?

Actually, I take that back: calling locate-file with last arg 1 is
subtly different from calling it with last arg file-executable-p.  So
I think we should either fix openp to use the same code as
file-executable-p, or not use 1 here.

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

[Stefan Monnier]

>> Actually, looking at the definition of executable-find, I'm surprised it
>> doesn't use locate-file.
> IIRC, executable-find was in existence longe before you added
> locate-file.

Yes, what I meant was that I was surprised I didn't change executable-find
back when I added locate-file (especially since I had added exec-suffixes
not that long before IIRC).

>> The new code is nothing else than a call to locate-file and I'd argue
>> that Eli's change from executable-find to locate-file is a bad idea and
>> instead we should simply move executable-find from executable.el to
>> subr.el.

> Well, if you are going to use integer values as the last arg to
> locate-file (which is deprecated usage, as the doc string says), why
> not call locate-file-internal directly and save a few cycles?

I could but the intention of using an integer arg wasn't to speed things up
but to more closely match the behavior of call-process and start-process.

> Also, I think this should go into files.el, not subr.el, since
> locate-file is in files.el.

Good point.


        Stefan