>> 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 (especiall
> Date: Sun, 08 May 2005 22:02:25 +0300
> From: "Eli Zaretskii" <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], 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-interna
> Cc: Nick Roberts <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
> emacs-devel@gnu.org
> From: Stefan Monnier <[EMAIL PROTECTED]>
> 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 w
> From: Nick Roberts <[EMAIL PROTECTED]>
> 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.
> 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 `ca
Yes. locate-file seems useful enough to justify a description in the Lisp
Reference Manual.
I agree. Would someone like to write this?
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
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
> > 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 Lis
> From: Nick Roberts <[EMAIL PROTECTED]>
> 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.
> Howev
> 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
> > 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: func
> From: Nick Roberts <[EMAIL PROTECTED]>
> Date: Fri, 6 May 2005 09:02:51 +1200
> Cc: Eli Zaretskii <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
> 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
> From: Nick Roberts <[EMAIL PROTECTED]>
> Date: Fri, 6 May 2005 09:02:51 +1200
> Cc: Eli Zaretskii <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
> emacs-devel@gnu.org
>
> Stefan Monnier writes:
> > >> ((not (file-executable-p "/lib/cpp")) "gcc -E -C -")
> >
> > > Right, but please amend this
> From: "Jan D." <[EMAIL PROTECTED]>
> 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
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
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 it
> > 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 kno
>> ((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
__
> From: Stefan Monnier <[EMAIL PROTECTED]>
> Date: Thu, 05 May 2005 10:17:14 -0400
> Cc: Magnus Henoch <[EMAIL PROTECTED]>, 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 p
> From: Nick Roberts <[EMAIL PROTECTED]>
> Date: Thu, 5 May 2005 22:58:45 +1200
> Cc: Stefan Monnier <[EMAIL PROTECTED]>, 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 al
> 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-execu
> > > ??? 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
> 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
sp
> From: Stefan Monnier <[EMAIL PROTECTED]>
> 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 us
> > 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 berk
> 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
On 5/3/05, Stefan Monnier <[EMAIL PROTECTED]> 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 tha
> From: Stefan Monnier <[EMAIL PROTECTED]>
> Date: Mon, 02 May 2005 18:16:33 -0400
> Cc: "Jan D." <[EMAIL PROTECTED]>, 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
>
>> 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 pr
> > 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
> 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 t
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 or
Nick Roberts <[EMAIL PROTECTED]> 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
___
Emacs-devel mailing list
Emacs-devel@gnu.o
> 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
>> 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 s
> 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 see
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-pr
> 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 mainta
> >> 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
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
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 swit
> 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 mak
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/c
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
>> 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
> 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 op
> From: Stefan Monnier <[EMAIL PROTECTED]>
> 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"
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(
48 matches
Mail list logo
