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

[Lennart Borgman <lennart.borgman@gmail.com>]

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.