Thread: [cedet-semantic] Semanticdb C include file search and sub-directories
Brought to you by:
zappo
From: <lu...@gn...> - 2009-07-08 17:18:38
|
Hello, The GNU Guile C source code has the following layout: / lib *.h <-- Gnulib headers libguile *.h <-- Guile headers Source files under libguile have #includes like this: #include <stdio.h> /* This file may come from the system's libc or from Gnulib's $(GUILE)/lib/stdio.h. */ #include "libguile/_scm.h" /* This file is in the same directory as the C file that includes it. */ #include "libguile/generated.h" /* If $builddir != $srcdir, then this file is not in the same directory as the C file that includes it. */ The typical CPPFLAGS are: -I$(top_srcdir)/lib -I$(top_builddir)/lib \ -I$(top_srcdir) -I$(top_builddir) When the Guile source tree is added to `semanticdb-project-roots', the "libguile/*.h" files are not found; however, when replacing "libguile/foo.h" by "foo.h", Semanticdb does find it. How can Semanticdb be taught how to find "libguile/foo.h"? I'm unsure about the <stdio.h> and "libguile/generated.h" cases, but how can they be handled? Thanks, Ludo'. |
From: <lu...@gn...> - 2009-07-16 12:15:26
|
Hello, Just a reminder that I'm still interested in hearing about tricks to address this issue. :-) Thanks, Ludo'. lu...@gn... (Ludovic Courtès) writes: > Hello, > > The GNU Guile C source code has the following layout: > > / > lib > *.h <-- Gnulib headers > libguile > *.h <-- Guile headers > > Source files under libguile have #includes like this: > > #include <stdio.h> /* This file may come from the system's libc or > from Gnulib's $(GUILE)/lib/stdio.h. */ > #include "libguile/_scm.h" /* This file is in the same directory as > the C file that includes it. */ > #include "libguile/generated.h" /* If $builddir != $srcdir, then this > file is not in the same directory > as the C file that includes it. */ > > The typical CPPFLAGS are: > > -I$(top_srcdir)/lib -I$(top_builddir)/lib \ > -I$(top_srcdir) -I$(top_builddir) > > When the Guile source tree is added to `semanticdb-project-roots', the > "libguile/*.h" files are not found; however, when replacing > "libguile/foo.h" by "foo.h", Semanticdb does find it. > > How can Semanticdb be taught how to find "libguile/foo.h"? > > I'm unsure about the <stdio.h> and "libguile/generated.h" cases, but how > can they be handled? > > Thanks, > Ludo'. > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge |
From: Michael R. <re...@gm...> - 2009-07-16 12:35:35
|
Hi I remember having trouble with includes in subdirs as well. I found that using even a bare minimum ede-cpp-root-project instead of just semanticdb-project- roots made things work a lot better. You might try that. Dunno what happens behind the scenes, though... Put something like this in your .emacs: (ede-cpp-root-project "ProjectName" :file "/path/to/project/Makefile" :include-path '( "subdir" ) ) ":file" would be some file in your $(top_srcdir). For libguile/*.h headers to be found the include-path shouldn't even be necessary. You could set it to "lib" though, for $(GUILE)/lib/stdio.h to be found. Greets Michael On Thursday 16 July 2009 14:11:26 Ludovic Courtès wrote: > Hello, > > Just a reminder that I'm still interested in hearing about tricks to > address this issue. :-) > > Thanks, > Ludo'. > > lu...@gn... (Ludovic Courtès) writes: > > Hello, > > > > The GNU Guile C source code has the following layout: > > > > / > > lib > > *.h <-- Gnulib headers > > libguile > > *.h <-- Guile headers > > > > Source files under libguile have #includes like this: > > > > #include <stdio.h> /* This file may come from the system's libc or > > from Gnulib's $(GUILE)/lib/stdio.h. */ > > #include "libguile/_scm.h" /* This file is in the same directory as > > the C file that includes it. */ > > #include "libguile/generated.h" /* If $builddir != $srcdir, then this > > file is not in the same directory > > as the C file that includes it. */ > > > > The typical CPPFLAGS are: > > > > -I$(top_srcdir)/lib -I$(top_builddir)/lib \ > > -I$(top_srcdir) -I$(top_builddir) > > > > When the Guile source tree is added to `semanticdb-project-roots', the > > "libguile/*.h" files are not found; however, when replacing > > "libguile/foo.h" by "foo.h", Semanticdb does find it. > > > > How can Semanticdb be taught how to find "libguile/foo.h"? > > > > I'm unsure about the <stdio.h> and "libguile/generated.h" cases, but how > > can they be handled? > > > > Thanks, > > Ludo'. > > > > > > ------------------------------------------------------------------------- > >----- Enter the BlackBerry Developer Challenge > > This is your chance to win up to $100,000 in prizes! For a limited time, > > vendors submitting new applications to BlackBerry App World(TM) will have > > the opportunity to enter the BlackBerry Developer Challenge. See full > > prize details at: http://p.sf.net/sfu/Challenge > > --------------------------------------------------------------------------- >--- Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > cedet-semantic mailing list > ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-semantic |
From: <lu...@gn...> - 2009-07-16 14:53:38
|
Hi, Michael Reiher <re...@gm...> writes: > I remember having trouble with includes in subdirs as well. I found that using > even a bare minimum ede-cpp-root-project instead of just semanticdb-project- > roots made things work a lot better. You might try that. Dunno what happens > behind the scenes, though... Actually, creating an EDE project (with `ede-new') appears to fix thing "automagically"---I guess this is expected since it's an Automake project, which EDE is supposed to be able to handle automatically. Thanks for putting me on the right track! Ludo'. |
From: <lu...@gn...> - 2009-07-16 15:41:32
|
Hello, lu...@gn... (Ludovic Courtès) writes: > ------------------------------------------------------------------------------ > Enter the XXX Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to XXX App World(TM) will have > the opportunity to enter the XXX Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge I find it annoying to have ads appended to my own messages without my consent. Is there anything that can be done about it? Eric: Would you be willing/able to host the mailing list elsewhere (e.g., at sv.gnu.org)? Thanks, Ludo'. |
From: Eric M. L. <er...@si...> - 2009-07-17 02:23:20
|
On Thu, 2009-07-16 at 17:41 +0200, Ludovic Courtès wrote: > Hello, > > lu...@gn... (Ludovic Courtès) writes: > > > ------------------------------------------------------------------------------ > > Enter the XXX Developer Challenge > > This is your chance to win up to $100,000 in prizes! For a limited time, > > vendors submitting new applications to XXX App World(TM) will have > > the opportunity to enter the XXX Developer Challenge. See full prize > > details at: http://p.sf.net/sfu/Challenge > > I find it annoying to have ads appended to my own messages without my > consent. > > Is there anything that can be done about it? Eric: Would you be > willing/able to host the mailing list elsewhere (e.g., at sv.gnu.org)? Hi Ludo I didn't see any options for removing the ads. I'm somewhat ambivalent about the whole thing since they provide a nice service for free and are just trying to make a buck. I'm also on savannah, and when I last looked into it, it was pretty spartan. I'm not sure about lately though. Mostly I just want to hack Emacs in Emacs and don't really want to deal with or learn that stuff if I can get away with it. I no longer write code for a living, so this is just fun time for me. If someone who already works w/ the GNU folks on stuff wants to take on the CEDET project management, shuffle stuff around, make it 'better', etc, that'd be cool, as long as I don't get stuck with some half-working project after it's no longer interesting for them. On the whole, however, I'd guess that the vast amount of data stored on SF logging CEDET's history has a lot of value that would be sad to loose. Eric |
From: <lu...@gn...> - 2009-07-17 08:25:53
|
Hello, "Eric M. Ludlam" <er...@si...> writes: > I didn't see any options for removing the ads. I'm somewhat > ambivalent about the whole thing since they provide a nice service for > free and are just trying to make a buck. Well, another concern for me is that they're also promoting (and using, IIRC) proprietary software. > I'm also on savannah, and when I last looked into it, it was pretty > spartan. I'm not sure about lately though. It has mailing lists, bug trackers, web hosting, support for several VCS, etc. (all of which are ad-free). Did you have any particular feature in mind? > On the whole, however, I'd guess that the vast amount of data stored > on SF logging CEDET's history has a lot of value that would be sad to > loose. I guess the source code repository, web pages, and mailing list archives could be retrieved and moved. Just to be clear, though: I was not advocating moving the whole CEDET project to Savannah (I'd like it, but it's time-consuming and I'm not volunteering to do it anyway ;-)), just the mailing list. Thanks, Ludo'. |
From: Eric M. L. <er...@si...> - 2009-07-18 13:29:43
|
On Fri, 2009-07-17 at 10:25 +0200, Ludovic Courtès wrote: > Hello, > > "Eric M. Ludlam" <er...@si...> writes: > > [Savannah] has mailing lists, bug trackers, web hosting, support for several > VCS, etc. (all of which are ad-free). Did you have any particular > feature in mind? At the time Savannah didn't exist, and when it first appeared, it was the web interface that was kind of lame. These days, the SF web interface has changed and become harder for me to figure out. Eric |