CEDET calls cpp -E -dM -x c++ /dev/null

CEDET calls cpp -E -dM -x c++ /dev/null

[Lennart Borgman]

CEDET does the call above in semantic-gcc-setup. Doing that from the
command line using MingGW on w32 fails.

It fails because /dev/null is not valid on w32. Shouldn't it be NUL
there? However looking through Emacs lisp sources I see several uses
of just /dev/null. Wouldn't it be better to use some defsubst for
this?

Now, if the command instead is

    cpp -E -dM -x c++ nul

it fails for me with

  cpp: installation problem, cannot exec `cc1plus': No such file or directory

Does it work for anyone else using MinGW? What should perhaps be used instead?

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Eli Zaretskii]

> Date: Wed, 1 Jul 2009 21:06:17 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: Alex Ott <alexott@gmail.com>, "Eric M. Ludlam" <eric@siege-engine.com>
> 
> CEDET does the call above in semantic-gcc-setup. Doing that from the
> command line using MingGW on w32 fails.
> 
> It fails because /dev/null is not valid on w32. Shouldn't it be NUL
> there?

Yes.

> However looking through Emacs lisp sources I see several uses
> of just /dev/null.

They are all bugs, unless they are intended to work only with Unix and
GNU systems.

> Wouldn't it be better to use some defsubst for this?

We already have one: the Lisp variable null-device holds the name of
the device appropriate for the underlying OS.

> Now, if the command instead is
> 
>     cpp -E -dM -x c++ nul
> 
> it fails for me with
> 
>   cpp: installation problem, cannot exec `cc1plus': No such file or directory

This works for me.  What version of cpp do you have?  I have this:

    D:\usr\eli\data>cpp --version
    cpp (GCC) 3.4.2 (mingw-special)
    Copyright (C) 2004 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Lennart Borgman]

On Wed, Jul 1, 2009 at 9:20 PM, Eli Zaretskii<eliz@gnu.org> wrote:
>> Date: Wed, 1 Jul 2009 21:06:17 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Cc: Alex Ott <alexott@gmail.com>, "Eric M. Ludlam" <eric@siege-engine.com>
>>
>> CEDET does the call above in semantic-gcc-setup. Doing that from the
>> command line using MingGW on w32 fails.
>>
>> It fails because /dev/null is not valid on w32. Shouldn't it be NUL
>> there?
>
> Yes.
>
>> However looking through Emacs lisp sources I see several uses
>> of just /dev/null.
>
> They are all bugs, unless they are intended to work only with Unix and
> GNU systems.

Thanks Eli. Should we file a bug report for this so it perhaps will
not be forgotten?


>> Wouldn't it be better to use some defsubst for this?
>
> We already have one: the Lisp variable null-device holds the name of
> the device appropriate for the underlying OS.

I think Info would be glad to know. Somewhere in "Operating System Interface"?


>> Now, if the command instead is
>>
>>     cpp -E -dM -x c++ nul
>>
>> it fails for me with
>>
>>   cpp: installation problem, cannot exec `cc1plus': No such file or directory
>
> This works for me.  What version of cpp do you have?  I have this:
>
>    D:\usr\eli\data>cpp --version
>    cpp (GCC) 3.4.2 (mingw-special)
>    Copyright (C) 2004 Free Software Foundation, Inc.
>    This is free software; see the source for copying conditions.  There is NO
>    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

cpp (GCC) 3.4.5 (mingw-vista special r3)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Hm, maybe I am using a release candidate ...?

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Eli Zaretskii]

> Date: Wed, 1 Jul 2009 21:25:47 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: emacs-devel@gnu.org, alexott@gmail.com, eric@siege-engine.com
> 
> On Wed, Jul 1, 2009 at 9:20 PM, Eli Zaretskii<eliz@gnu.org> wrote:
> >> Date: Wed, 1 Jul 2009 21:06:17 +0200
> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> Cc: Alex Ott <alexott@gmail.com>, "Eric M. Ludlam" <eric@siege-engine.com>
> >>
> >> CEDET does the call above in semantic-gcc-setup. Doing that from the
> >> command line using MingGW on w32 fails.
> >>
> >> It fails because /dev/null is not valid on w32. Shouldn't it be NUL
> >> there?
> >
> > Yes.
> >
> >> However looking through Emacs lisp sources I see several uses
> >> of just /dev/null.
> >
> > They are all bugs, unless they are intended to work only with Unix and
> > GNU systems.
> 
> Thanks Eli. Should we file a bug report for this so it perhaps will
> not be forgotten?

Yes, please.

> >> Wouldn't it be better to use some defsubst for this?
> >
> > We already have one: the Lisp variable null-device holds the name of
> > the device appropriate for the underlying OS.
> 
> I think Info would be glad to know. Somewhere in "Operating System Interface"?

I guess so.  "Operating System Environment" sounds like a good place.
shell-file-name and shell-command-switch should probably be documented
as well.

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Lennart Borgman]

On Wed, Jul 1, 2009 at 9:25 PM, Lennart
Borgman<lennart.borgman@gmail.com> wrote:
>>> Now, if the command instead is
>>>
>>>     cpp -E -dM -x c++ nul
>>>
>>> it fails for me with
>>>
>>>   cpp: installation problem, cannot exec `cc1plus': No such file or directory
>>
>> This works for me.  What version of cpp do you have?  I have this:
>>
>>    D:\usr\eli\data>cpp --version
>>    cpp (GCC) 3.4.2 (mingw-special)
>>    Copyright (C) 2004 Free Software Foundation, Inc.
>>    This is free software; see the source for copying conditions.  There is NO
>>    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> cpp (GCC) 3.4.5 (mingw-vista special r3)
> Copyright (C) 2004 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Hm, maybe I am using a release candidate ...?

Reinstalled. Still same version, but now it works.

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Sean O'Rourke]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 1 Jul 2009 21:25:47 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> I think Info would be glad to know. Somewhere in "Operating System Interface"?
>
> I guess so.  "Operating System Environment" sounds like a good place.
> shell-file-name and shell-command-switch should probably be documented
> as well.

Here's a patch putting them all in "Operating System Environment"
using what seems to be the standard wording.

/s


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: foo.diff --]
[-- Type: text/x-patch, Size: 1173 bytes --]

diff --git a/doc/lispref/ChangeLog b/doc/lispref/ChangeLog
index dbff044..2cc4e03 100644
--- a/doc/lispref/ChangeLog
+++ b/doc/lispref/ChangeLog
@@ -1,3 +1,8 @@
+2009-07-01  Sean O'Rourke  <seano@cs.ucla.edu>
+
+	* os.texi (System Environment): document null-device,
+	shell-file-name, and shell-command-switch.
+
 2009-06-24  Chong Yidong  <cyd@stupidchicken.com>
 
 	* display.texi (Window Systems): Add ns to the list.
diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi
index 07ae1a0..1073f2a 100644
--- a/doc/lispref/os.texi
+++ b/doc/lispref/os.texi
@@ -991,6 +991,20 @@ in the system's terminal driver, before Emacs was started.
 The value is @code{nil} if Emacs is running under a window system.
 @end defvar
 
+@defvar null-device
+This variable holds the name of the system's null ouput device, used
+to discard a program's output.
+@end defvar
+
+@defvar shell-file-name
+This variable holds the name of the system shell.
+@end defvar
+
+@defvar shell-command-switch
+This variable holds the switch used to have the shell execute its
+command line argument.
+@end defvar
+
 @node User Identification
 @section User Identification
 @cindex user identification

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Lennart Borgman]

On Wed, Jul 1, 2009 at 10:01 PM, Sean O'Rourke<seano@cs.ucla.edu> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Wed, 1 Jul 2009 21:25:47 +0200
>>> From: Lennart Borgman <lennart.borgman@gmail.com>
>>> I think Info would be glad to know. Somewhere in "Operating System Interface"?
>>
>> I guess so.  "Operating System Environment" sounds like a good place.
>> shell-file-name and shell-command-switch should probably be documented
>> as well.
>
> Here's a patch putting them all in "Operating System Environment"
> using what seems to be the standard wording.

Looks good IMO, but please add that null-device should be used instead
of /dev/null. Then it will be possible to search for it in the manual.

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Lennart Borgman]

>> >> However looking through Emacs lisp sources I see several uses
>> >> of just /dev/null.
>> >
>> > They are all bugs, unless they are intended to work only with Unix and
>> > GNU systems.
>>
>> Thanks Eli. Should we file a bug report for this so it perhaps will
>> not be forgotten?
>
> Yes, please.

Done.

I see another problem in semantic-gcc-setup. It tries to guess the
include paths and does this

  (let* ((try-paths (list "/usr/include" (concat prefix "/include")
			  (concat prefix "/include/c++/" ver)
			  (concat prefix "/include/c++/" ver "/" host )
			  )))

Can't gcc or cpp give some better information about include paths that
semantic can use? Where is this information?

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Sean O'Rourke]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

Lennart Borgman <lennart.borgman@gmail.com> writes:
> Looks good IMO, but please add that null-device should be used
> instead of /dev/null. Then it will be possible to search for it
> in the manual.

Does this do it, or do I need to use some other code for
/dev/null?

/s


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: foo.diff --]
[-- Type: text/x-patch, Size: 1236 bytes --]

diff --git a/doc/lispref/ChangeLog b/doc/lispref/ChangeLog
index dbff044..2cc4e03 100644
--- a/doc/lispref/ChangeLog
+++ b/doc/lispref/ChangeLog
@@ -1,3 +1,8 @@
+2009-07-01  Sean O'Rourke  <seano@cs.ucla.edu>
+
+	* os.texi (System Environment): document null-device,
+	shell-file-name, and shell-command-switch.
+
 2009-06-24  Chong Yidong  <cyd@stupidchicken.com>
 
 	* display.texi (Window Systems): Add ns to the list.
diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi
index 07ae1a0..ff415a8 100644
--- a/doc/lispref/os.texi
+++ b/doc/lispref/os.texi
@@ -991,6 +991,21 @@ in the system's terminal driver, before Emacs was started.
 The value is @code{nil} if Emacs is running under a window system.
 @end defvar
 
+@defvar null-device
+This variable holds the name of the system's null ouput device, used
+to discard a program's output.  Use this variable instead of
+@file{/dev/null} or @file{NUL}.
+@end defvar
+
+@defvar shell-file-name
+This variable holds the name of the system shell.
+@end defvar
+
+@defvar shell-command-switch
+This variable holds the switch used to have the shell execute its
+command line argument.
+@end defvar
+
 @node User Identification
 @section User Identification
 @cindex user identification

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Eli Zaretskii]

> Date: Wed, 1 Jul 2009 22:25:32 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: emacs-devel@gnu.org, alexott@gmail.com, eric@siege-engine.com
> 
> I see another problem in semantic-gcc-setup. It tries to guess the
> include paths and does this
> 
>   (let* ((try-paths (list "/usr/include" (concat prefix "/include")
> 			  (concat prefix "/include/c++/" ver)
> 			  (concat prefix "/include/c++/" ver "/" host )
> 			  )))
> 
> Can't gcc or cpp give some better information about include paths that
> semantic can use? Where is this information?

I thought one of the -print-* options could show the place of the
headers, but I cannot get them to do this.  This is the closest:

    D:\usr\eli\data>cpp -print-file-name=libmingwex.a
    D:/usr/bin/../lib/gcc/mingw32/3.4.2/../../../libmingwex.a

I guess the place where the headers live should be customizable
instead of being hardcoded.

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Eric M. Ludlam]

On Thu, 2009-07-02 at 06:24 +0300, Eli Zaretskii wrote:
> > Date: Wed, 1 Jul 2009 22:25:32 +0200
> > From: Lennart Borgman <lennart.borgman@gmail.com>
> > Cc: emacs-devel@gnu.org, alexott@gmail.com, eric@siege-engine.com
> > 
> > I see another problem in semantic-gcc-setup. It tries to guess the
> > include paths and does this
> > 
> >   (let* ((try-paths (list "/usr/include" (concat prefix "/include")
> > 			  (concat prefix "/include/c++/" ver)
> > 			  (concat prefix "/include/c++/" ver "/" host )
> > 			  )))
> > 
> > Can't gcc or cpp give some better information about include paths that
> > semantic can use? Where is this information?
> 
> I thought one of the -print-* options could show the place of the
> headers, but I cannot get them to do this.  This is the closest:
> 
>     D:\usr\eli\data>cpp -print-file-name=libmingwex.a
>     D:/usr/bin/../lib/gcc/mingw32/3.4.2/../../../libmingwex.a
> 
> I guess the place where the headers live should be customizable
> instead of being hardcoded.

Hi,

  The code that is looking up header directories that Lennart quoted is
attempting to find a reasonable default because the customization step
can be confusing.  There are many possible paths that need to be
identified and setup, so this code is just trying to remove one set of
customizations that might be needed.  A side effect is a desire to make
it "perfect" for all situations.  Making the list of dirs for this code
to test customizable is moot, since it is just as easy to customize the
system include path for headers instead.

  Getting better output from gcc, such as -print-file-name, would be
helpful.

Thanks
Eric

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Lennart Borgman]

On Thu, Jul 2, 2009 at 5:34 AM, Eric M. Ludlam<eric@siege-engine.com> wrote:
> On Thu, 2009-07-02 at 06:24 +0300, Eli Zaretskii wrote:
>> > Date: Wed, 1 Jul 2009 22:25:32 +0200
>> > From: Lennart Borgman <lennart.borgman@gmail.com>
>> > Cc: emacs-devel@gnu.org, alexott@gmail.com, eric@siege-engine.com
>> >
>> > I see another problem in semantic-gcc-setup. It tries to guess the
>> > include paths and does this
>> >
>> >   (let* ((try-paths (list "/usr/include" (concat prefix "/include")
>> >                       (concat prefix "/include/c++/" ver)
>> >                       (concat prefix "/include/c++/" ver "/" host )
>> >                       )))
>> >
>> > Can't gcc or cpp give some better information about include paths that
>> > semantic can use? Where is this information?
>>
>> I thought one of the -print-* options could show the place of the
>> headers, but I cannot get them to do this.  This is the closest:
>>
>>     D:\usr\eli\data>cpp -print-file-name=libmingwex.a
>>     D:/usr/bin/../lib/gcc/mingw32/3.4.2/../../../libmingwex.a
>>
>> I guess the place where the headers live should be customizable
>> instead of being hardcoded.
>
> Hi,
>
>  The code that is looking up header directories that Lennart quoted is
> attempting to find a reasonable default because the customization step
> can be confusing.  There are many possible paths that need to be
> identified and setup, so this code is just trying to remove one set of
> customizations that might be needed.  A side effect is a desire to make
> it "perfect" for all situations.  Making the list of dirs for this code
> to test customizable is moot, since it is just as easy to customize the
> system include path for headers instead.
>
>  Getting better output from gcc, such as -print-file-name, would be
> helpful.

Eric, I looked at your code again and realize that you are using "gcc
-v" to get info. On w32 it gives "--prefix=/mingw" which lacks the
drive letter and therefore is useless. I have filed a bug report

    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624

However for now a workaround must be used and I suggest on w32 using
the information from

         (let* ((gcc-exe (locate-file "gcc" exec-path exec-suffixes
'executable))
                (gcc-root (expand-file-name ".." (file-name-directory gcc-exe)))

I believe gcc-root contains the info that --prefix should have given.

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Eli Zaretskii]

> Date: Thu, 2 Jul 2009 20:13:06 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, alexott@gmail.com
> 
> Eric, I looked at your code again and realize that you are using "gcc
> -v" to get info. On w32 it gives "--prefix=/mingw" which lacks the
> drive letter and therefore is useless. I have filed a bug report
> 
>     http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624

As you already saw in the responses there, the value of --prefix
cannot be helpful when you install precompiled binaries in a different
directory anyway.  It is only helpful if your GCC was built on the
same machine it is used.  So I think it's futile to pursue this line
of fixing the problem.

> However for now a workaround must be used and I suggest on w32 using
> the information from
> 
>          (let* ((gcc-exe (locate-file "gcc" exec-path exec-suffixes
> 'executable))
>                 (gcc-root (expand-file-name ".." (file-name-directory gcc-exe)))
> 
> I believe gcc-root contains the info that --prefix should have given.

Only if none of the *_INCLUDE_PATH variables is set in the
environment.  So I think CEDET needs to inspect those variables first.

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Lennart Borgman]

On Thu, Jul 2, 2009 at 9:29 PM, Eli Zaretskii<eliz@gnu.org> wrote:
>> Date: Thu, 2 Jul 2009 20:13:06 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, alexott@gmail.com
>>
>> Eric, I looked at your code again and realize that you are using "gcc
>> -v" to get info. On w32 it gives "--prefix=/mingw" which lacks the
>> drive letter and therefore is useless. I have filed a bug report
>>
>>     http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624
>
> As you already saw in the responses there, the value of --prefix
> cannot be helpful when you install precompiled binaries in a different
> directory anyway.  It is only helpful if your GCC was built on the
> same machine it is used.  So I think it's futile to pursue this line
> of fixing the problem.
>
>> However for now a workaround must be used and I suggest on w32 using
>> the information from
>>
>>          (let* ((gcc-exe (locate-file "gcc" exec-path exec-suffixes
>> 'executable))
>>                 (gcc-root (expand-file-name ".." (file-name-directory gcc-exe)))
>>
>> I believe gcc-root contains the info that --prefix should have given.
>
> Only if none of the *_INCLUDE_PATH variables is set in the
> environment.  So I think CEDET needs to inspect those variables first.

Thanks, there are more env vars for this, see
http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html

From the page http://www.mingw.org/wiki/IncludePathHOWTO it looks like
the way to get the include path used by gcc is something like

   touch temp.c
   gcc -v -c temp.c -o NUL (or /dev/null)

I believe this works on all os:es with gcc. It seems to include CPATH
and C_INCLUDE_PATH etc. However do not quite understand the output and
how to parse it. Could someone explain?

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
> Thanks, there are more env vars for this, see
> http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
>
> From the page http://www.mingw.org/wiki/IncludePathHOWTO it looks like
> the way to get the include path used by gcc is something like
>
>    touch temp.c
>    gcc -v -c temp.c -o NUL (or /dev/null)

Better to use something like this:  gcc -v -E -x c /dev/null
which doesn't require an input file or run unnecessary passes of the compiler.
(substitute NUL on windows)

> I believe this works on all os:es with gcc. It seems to include CPATH
> and C_INCLUDE_PATH etc. However do not quite understand the output and
> how to parse it. Could someone explain?

This part of the output seems to have pretty well-defined markers, and
lists the include directories one per line:

   #include "..." search starts here:
   #include <...> search starts here:
    /usr/local/include
    /usr/lib/gcc/x86_64-linux-gnu/4.3.3/include
    /usr/lib/gcc/x86_64-linux-gnu/4.3.3/include-fixed
    /usr/include
   End of search list.

Looks easy enough to parse (since there's a space prepended to each
directory line, you don't even have to worry about a directory called
"End of search list.", though an embedded newline might cause a
mess... :).

Thanks,

-Miles

-- 
Learning, n. The kind of ignorance distinguishing the studious.

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Lennart Borgman]

On Fri, Jul 3, 2009 at 2:46 AM, Miles Bader<miles@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>> Thanks, there are more env vars for this, see
>> http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
>>
>> From the page http://www.mingw.org/wiki/IncludePathHOWTO it looks like
>> the way to get the include path used by gcc is something like
>>
>>    touch temp.c
>>    gcc -v -c temp.c -o NUL (or /dev/null)
>
> Better to use something like this:  gcc -v -E -x c /dev/null
> which doesn't require an input file or run unnecessary passes of the compiler.
> (substitute NUL on windows)

Yes, that is better. Thanks. I tried to use it like this

(defun semantic-gcc-query (gcc-cmd &rest gcc-option)
  "Query gcc.  Return a list of configurations.
GCC-CMD is an optional command to execute instead of \"gcc\""
  ;; $ gcc -v
  ;;
  (let ((buff (get-buffer-create " *gcc-query*")))
    (save-excursion
      (set-buffer buff)
      (erase-buffer)
      (condition-case nil
          (apply 'call-process gcc-cmd nil buff nil gcc-option)
	(error ;; Some bogus directory for the first time perhaps?
	 (let ((default-directory (expand-file-name "~/")))
	   (condition-case nil
               (apply 'call-process gcc-cmd nil buff nil gcc-option)
	     (error ;; gcc doesn't exist???
	      nil)))))
      (prog1
	  (buffer-string)
	(kill-buffer buff)
        ))))

(defun semantic-gcc-get-include-paths (lang)
  (let* ((gcc-cmd (cond
                   ((string= lang "c") "gcc")
                   (t (error "Unknown lang: %s" lang))))
         (gcc-output (semantic-gcc-query gcc-cmd "-v" "-E" "-x" lang)))
    ))

However calling (semantic-gcc-get-include-paths "c") does not catch
the output I want to gcc-output. I get

Result: "gcc.exe: warning: `-x c' after last input file has no
effect\nReading specs from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs\nConfigured with:
../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld
--with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw
--enable-threads --disable-nls
--enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--disable-shared --enable-sjlj-exceptions --enable-libgcj
--disable-java-awt --without-x --enable-java-gc=boehm
--disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug\nThread model:
win32\ngcc version 3.4.5 (mingw-vista special r3)\n"



>> I believe this works on all os:es with gcc. It seems to include CPATH
>> and C_INCLUDE_PATH etc. However do not quite understand the output and
>> how to parse it. Could someone explain?
>
> This part of the output seems to have pretty well-defined markers, and
> lists the include directories one per line:
>
>   #include "..." search starts here:
>   #include <...> search starts here:
>    /usr/local/include
>    /usr/lib/gcc/x86_64-linux-gnu/4.3.3/include
>    /usr/lib/gcc/x86_64-linux-gnu/4.3.3/include-fixed
>    /usr/include
>   End of search list.
>
> Looks easy enough to parse (since there's a space prepended to each
> directory line, you don't even have to worry about a directory called
> "End of search list.", though an embedded newline might cause a
> mess... :).

Yes, but what about the two different categories of include paths. How
 should they be handled? Just use both?


> Thanks,
>
> -Miles
>
> --
> Learning, n. The kind of ignorance distinguishing the studious.
>
>
>
>

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Eli Zaretskii]

> Date: Fri, 3 Jul 2009 03:13:12 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: "Eric M. Ludlam" <eric@siege-engine.com>,
> 	Emacs-Devel devel <emacs-devel@gnu.org>
> 
> (defun semantic-gcc-get-include-paths (lang)
>   (let* ((gcc-cmd (cond
>                    ((string= lang "c") "gcc")
>                    (t (error "Unknown lang: %s" lang))))
>          (gcc-output (semantic-gcc-query gcc-cmd "-v" "-E" "-x" lang)))
>     ))
> 
> However calling (semantic-gcc-get-include-paths "c") does not catch
> the output I want to gcc-output. I get
> 
> Result: "gcc.exe: warning: `-x c' after last input file has no effect\n

This is because your forgot to append null-device to the arguments you
pass to semantic-gcc-get-include-paths.  So the command line ends with
a "-x c", which, as GCC tells you, is quite pointless without a file
name after it.

> Yes, but what about the two different categories of include paths. How
>  should they be handled? Just use both?

Yes, both.

Btw, as Miles's output shows, there could be more than 2 directories
in this list, and all of them should be looked in.  AFAIR, the order
of lookup should be the order in which GCC prints them, because that's
what GCC does.

Re: CEDET calls cpp -E -dM -x c++ /dev/null

[Lennart Borgman]

On Fri, Jul 3, 2009 at 11:36 AM, Eli Zaretskii<eliz@gnu.org> wrote:
>> Date: Fri, 3 Jul 2009 03:13:12 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Cc: "Eric M. Ludlam" <eric@siege-engine.com>,
>>       Emacs-Devel devel <emacs-devel@gnu.org>
>>
>> (defun semantic-gcc-get-include-paths (lang)
>>   (let* ((gcc-cmd (cond
>>                    ((string= lang "c") "gcc")
>>                    (t (error "Unknown lang: %s" lang))))
>>          (gcc-output (semantic-gcc-query gcc-cmd "-v" "-E" "-x" lang)))
>>     ))
>>
>> However calling (semantic-gcc-get-include-paths "c") does not catch
>> the output I want to gcc-output. I get
>>
>> Result: "gcc.exe: warning: `-x c' after last input file has no effect\n
>
> This is because your forgot to append null-device to the arguments you
> pass to semantic-gcc-get-include-paths.  So the command line ends with
> a "-x c", which, as GCC tells you, is quite pointless without a file
> name after it.

Thanks.


>> Yes, but what about the two different categories of include paths. How
>>  should they be handled? Just use both?
>
> Yes, both.
>
> Btw, as Miles's output shows, there could be more than 2 directories
> in this list, and all of them should be looked in.  AFAIR, the order
> of lookup should be the order in which GCC prints them, because that's
> what GCC does.

What about this version?

(defun semantic-gcc-query (gcc-cmd &rest gcc-option)
  "Return command output.
GCC-CMD is the command to execute and GCC-OPTIONS are the options
to give to the command."
  ;; $ gcc -v
  ;;
  (let ((buff (get-buffer-create " *gcc-query*")))
    (save-excursion
      (set-buffer buff)
      (erase-buffer)
      (condition-case nil
          (apply 'call-process gcc-cmd nil (cons buff t) nil gcc-option)
	(error ;; Some bogus directory for the first time perhaps?
	 (let ((default-directory (expand-file-name "~/")))
	   (condition-case nil
               (apply 'call-process gcc-cmd nil (cons buff t) nil gcc-option)
	     (error ;; gcc doesn't exist???
	      nil)))))
      (prog1
	  (buffer-string)
	(kill-buffer buff)
        ))))

;;(semantic-gcc-get-include-paths "c")
;;(semantic-gcc-get-include-paths "c++")
(defun semantic-gcc-get-include-paths (lang)
  (let* ((gcc-cmd (cond
                   ((string= lang "c") "gcc")
                   ((string= lang "c++") "c++")
                   (t (error "Unknown lang: %s" lang))))
         (gcc-output (semantic-gcc-query gcc-cmd "-v" "-E" "-x" lang
null-device))
         (lines (split-string gcc-output "\n"))
         (include-marks 0)
         (inc-mark "#include ")
         (inc-mark-len (length "#include "))
         inc-path)
    (message "gcc-output=%s" gcc-output)
    (dolist (line lines)
      (when (> (length line) 1)
        (if (= 0 include-marks)
            (when (and (> (length line) inc-mark-len)
                       (string= inc-mark (substring line 0 inc-mark-len)))
              (setq include-marks (1+ include-marks)))
          (let ((chars (append line nil)))
            (when (= 32 (nth 0 chars))
              (when (if (memq system-type '(windows-nt))
                        (/= ?/ (nth 1 chars))
                      (= ?/ (nth 1 chars)))
                (add-to-list 'inc-path
                             (expand-file-name (substring line 1))
                             t)))))))
    inc-path))