CEDET

Hi,

I'm trying to setup Cedet to work properly on a project that uses Qt.

I can make it mostly working with a project defined for Qt:

   (ede-cpp-root-project "Qt" :file "/usr/local/Qt-4.8.0/q3porting.xml"
            :include-path '("/include")
            :system-include-path '("/usr/include/c++/4.7/"
                                   "/usr/include")
            :spp-table '(("Q_REQUIRED_RESULT" . "")
                         ("Q_CORE_EXPORT" . "")
                         ("Q_GUI_EXPORT" . "")
                         ("Q_SQL_EXPORT" . "")
                         ("Q_NETWORK_EXPORT" . "")
                         ("Q_SVG_EXPORT" . "")
                         ("Q_DECLARATIVE_EXPORT" . "")
                         ("Q_OPENGL_EXPORT" . "")
                         ("Q_MULTIMEDIA_EXPORT" . "")
                         ("Q_OPENVG_EXPORT" . "")
                         ("Q_XML_EXPORT" . "")
                         ("Q_XMLPATTERNS_EXPORT" . "")
                         ("Q_SCRIPT_EXPORT" . "")
                         ("Q_SCRIPTTOOLS_EXPORT" . "")
                         ("Q_COMPAT_EXPORT" . "")
                         ("Q_DBUS_EXPORT" . "")))

With this the code from qstring.h (just an example - others are
similar):

   class QStringRef;
   template <typename T> class QVector;

   class Q_CORE_EXPORT QString
   {
   public:
       inline QString();

properly "sees" the QString class definition. Without Q_CORE_EXPORT in
spp-table this doesn't work and QString is parsed as a variable of type
Q_CORE_EXPORT (checked by looking at output of bovinate) which is
probably expected.

This list of defines is not complete and it depends on Qt version and
configuration so when I found informations from Alex Ott's blog about
semantic-lex-c-preprocessor-symbol-file and from ede documentation about
spp-files I tried to change project definition to:

   (ede-cpp-root-project "Qt" :file "/usr/local/Qt-4.8.0/q3porting.xml"
            :include-path '("/include")
            :system-include-path '("/usr/include/c++/4.7/"
                                   "/usr/include")
            :spp-files '("include/Qt/qconfig.h"
                         "include/Qt/qconfig-large.h"
                         "include/Qt/qglobal.h"))

This doesn't work for me. 'class Q_CORE_EXPORT QString' is not
recognized as a class definition.

I've verified (at least I believe so) that spp-files is defined
correctly by issuing:

   (assoc "Q_CORE_EXPORT"
           (ede-preprocessor-map (ede-current-project "/usr/local/Qt-4.8.0")))

which gave me:

   ("Q_CORE_EXPORT")

so the symbol is found.

As I'm starting playing with elisp and cedet I feel confused searching
for new pieces of information that can help mi to understand what is
going on.

Tell me please what can I do to fix this or to debug this problem?

Regards
Tomasz Gajewski

Re: [CEDET-devel] Cedet and Qt - problems with parsing headers From: Eric M. Ludlam <eric@si...> - 2012-12-05 02:38 Hi Tomasz; A very useful debug tool for stuff like this for C++ is: M-x semantic-c-describe-environment RET which lists preprocessor tables and good stuff like that. Based on your text below, I think you are ok. I think your headers were parsed when things were in a 'bad' state, and then after you fixed the state, Semantic continues to pull bad data from cache files. You can delete cache files associated with your project directory, and start Emacs, and that will probably clean things up for you. We probably need some sort of "dirty all the semantic database tables" function for cases like this. Eric On 12/02/2012 07:22 PM, Tomasz Gajewski wrote: > > Hi, > > I'm trying to setup Cedet to work properly on a project that uses Qt. > > I can make it mostly working with a project defined for Qt: > > (ede-cpp-root-project "Qt" :file "/usr/local/Qt-4.8.0/q3porting.xml" > :include-path '("/include") > :system-include-path '("/usr/include/c++/4.7/" > "/usr/include") > :spp-table '(("Q_REQUIRED_RESULT" . "") > ("Q_CORE_EXPORT" . "") > ("Q_GUI_EXPORT" . "") > ("Q_SQL_EXPORT" . "") > ("Q_NETWORK_EXPORT" . "") > ("Q_SVG_EXPORT" . "") > ("Q_DECLARATIVE_EXPORT" . "") > ("Q_OPENGL_EXPORT" . "") > ("Q_MULTIMEDIA_EXPORT" . "") > ("Q_OPENVG_EXPORT" . "") > ("Q_XML_EXPORT" . "") > ("Q_XMLPATTERNS_EXPORT" . "") > ("Q_SCRIPT_EXPORT" . "") > ("Q_SCRIPTTOOLS_EXPORT" . "") > ("Q_COMPAT_EXPORT" . "") > ("Q_DBUS_EXPORT" . ""))) > > With this the code from qstring.h (just an example - others are > similar): > > class QStringRef; > template<typename T> class QVector; > > class Q_CORE_EXPORT QString > { > public: > inline QString(); > > properly "sees" the QString class definition. Without Q_CORE_EXPORT in > spp-table this doesn't work and QString is parsed as a variable of type > Q_CORE_EXPORT (checked by looking at output of bovinate) which is > probably expected. > > This list of defines is not complete and it depends on Qt version and > configuration so when I found informations from Alex Ott's blog about > semantic-lex-c-preprocessor-symbol-file and from ede documentation about > spp-files I tried to change project definition to: > > (ede-cpp-root-project "Qt" :file "/usr/local/Qt-4.8.0/q3porting.xml" > :include-path '("/include") > :system-include-path '("/usr/include/c++/4.7/" > "/usr/include") > :spp-files '("include/Qt/qconfig.h" > "include/Qt/qconfig-large.h" > "include/Qt/qglobal.h")) > > > This doesn't work for me. 'class Q_CORE_EXPORT QString' is not > recognized as a class definition. > > I've verified (at least I believe so) that spp-files is defined > correctly by issuing: > > (assoc "Q_CORE_EXPORT" > (ede-preprocessor-map (ede-current-project "/usr/local/Qt-4.8.0"))) > > which gave me: > > ("Q_CORE_EXPORT") > > so the symbol is found. > > As I'm starting playing with elisp and cedet I feel confused searching > for new pieces of information that can help mi to understand what is > going on. > > Tell me please what can I do to fix this or to debug this problem? > > Regards > Tomasz Gajewski > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > BUILD Helping you discover the best ways to construct your parallel projects. > http://goparallel.sourceforge.net > _______________________________________________ > Cedet-devel mailing list > Cedet-devel@... > https://lists.sourceforge.net/lists/listinfo/cedet-devel >

Re: [CEDET-devel] Cedet and Qt - problems with parsing headers From: Tomasz Gajewski <tomga@wp...> - 2012-12-05 19:49 "Eric M. Ludlam" <eric@...> writes: > Hi Tomasz; > > A very useful debug tool for stuff like this for C++ is: > > M-x semantic-c-describe-environment RET Thanks for this. 'semantic-lex-spp-describe' mentioned in result of this is especially useful. > I think your headers were parsed when things were in a 'bad' state, > and then after you fixed the state, Semantic continues to pull bad > data from cache files. > > You can delete cache files associated with your project directory, and > start Emacs, and that will probably clean things up for you. I have customized 'semanticdb-default-save-directory' and before each start of emacs I delete contents of this directory, so unless there are some other caches the problem is different. > We probably need some sort of "dirty all the semantic database tables" > function for cases like this. Probably it would be useful to have something like this on a project level but the problems I'm hitting are rather different. To describe what is happening I've added some defines to ':spp-table' and others left to be found in files from ':spp-files'. I'm deleting contents of semanticdb-default-save-directory directory and starting emacs. I open 'qstring.h' file and the content is parsed without any of defines from :spp-table nor :spp-files. Output of semantic-lex-spp-describe does not contain them either. If I close and open 'qstring.h' again output of semanticdb-default-save-directory macros from :spp-table are in the output but not those from :spp-files. If I force emacs to reparse this buffer (by modifying contents and reverting without save) then I can see that macro definitions from :spp-table where interpreted properly. When after that I do: M-: (ede-apply-target-options) RET then output of semantic-lex-spp-describe contains all macro definitions. Those from :spp-table and from :spp-files. But the trick with reverting buffer makes semantic-lex-spp-describe reporting only macros from :spp-table. Calling 'bovinate' after 'ede-apply-target-options' shows output from parser: ... ("QString" variable (:type ("Q_CORE_EXPORT" type (:prototype t :type "class") nil nil)) nil #<overlay from 2484 to 30889 in qstring.h>) ... just as there was no Q_CORE_EXPORT macro even though the result of semantic-lex-spp-describe contains definition for this: Q_CORE_EXPORT nil I'm not able to fix those problems yet (I don't even understand how you think it should work) but I think there are two kinds problems. First is that there is some race condition between parsing buffer (if it is first open file from project) and ede setting the environment for parsing (macro definitions). Second is that :spp-files option is somehow ignored during parsing. I hope my description of problem is helpful enough for you to quickly understand and fix those problems. Regards Tomasz Gajewski

Re: [CEDET-devel] Cedet and Qt - problems with parsing headers From: Eric M. Ludlam <eric@si...> - 2012-12-06 00:41 Hi Tomasz It looks like you are working on the Qt sources, right? Could you tar or zip up the smallest set of files that shows this behavior to email me? Include your latest .el with ede-cpp-root project in it and snippets that handle your semanticdb trick you described below, and any other CEDET config you might have. Thanks. This problem sounds familiar, but I last worked on spp-files not loading on startup back before the file-rename in the CEDET repository. At that time there was a problem parsing the :spp-files when Semantic was trying to parse the file you were in. If it is related to that, it might even be that your 'delete the cache files' trick is causing this problem. I'm hoping if I can figure this out, I can make a nice unit test out of your sample code. As a side note, if you want to completely bypass semanticdb saving files, you can use this in your .emacs file: (setq-default semanticdb-new-database-class 'semanticdb-project-database) This causes new tables to be a class that can't save, and thus, they don't save. I use this in the test harnesses so that the environment doesn't affect the running of the tests. Thanks Eric On 12/05/2012 02:49 PM, Tomasz Gajewski wrote: > "Eric M. Ludlam"<eric@...> writes: > >> Hi Tomasz; >> >> A very useful debug tool for stuff like this for C++ is: >> >> M-x semantic-c-describe-environment RET > > Thanks for this. 'semantic-lex-spp-describe' mentioned in result of this > is especially useful. > >> I think your headers were parsed when things were in a 'bad' state, >> and then after you fixed the state, Semantic continues to pull bad >> data from cache files. >> >> You can delete cache files associated with your project directory, and >> start Emacs, and that will probably clean things up for you. > > I have customized 'semanticdb-default-save-directory' and before each > start of emacs I delete contents of this directory, so unless there are > some other caches the problem is different. > >> We probably need some sort of "dirty all the semantic database tables" >> function for cases like this. > > Probably it would be useful to have something like this on a project > level but the problems I'm hitting are rather different. > > > To describe what is happening I've added some defines to ':spp-table' > and others left to be found in files from ':spp-files'. > > I'm deleting contents of semanticdb-default-save-directory directory and > starting emacs. I open 'qstring.h' file and the content is parsed > without any of defines from :spp-table nor :spp-files. Output of > semantic-lex-spp-describe does not contain them either. > > If I close and open 'qstring.h' again output of > semanticdb-default-save-directory macros from :spp-table are in the > output but not those from :spp-files. > > If I force emacs to reparse this buffer (by modifying contents and > reverting without save) then I can see that macro definitions from > :spp-table where interpreted properly. > > When after that I do: > > M-: (ede-apply-target-options) RET > > then output of semantic-lex-spp-describe contains all macro > definitions. Those from :spp-table and from :spp-files. But the trick > with reverting buffer makes semantic-lex-spp-describe reporting only > macros from :spp-table. > > Calling 'bovinate' after 'ede-apply-target-options' shows output from > parser: > > ... > ("QString" variable > (:type > ("Q_CORE_EXPORT" type > (:prototype t :type "class") > nil nil)) > nil #<overlay from 2484 to 30889 in qstring.h>) > ... > > just as there was no Q_CORE_EXPORT macro even though the result of > semantic-lex-spp-describe contains definition for this: > > Q_CORE_EXPORT nil > > > I'm not able to fix those problems yet (I don't even understand how you > think it should work) but I think there are two kinds problems. > > First is that there is some race condition between parsing buffer (if it > is first open file from project) and ede setting the environment for > parsing (macro definitions). > > Second is that :spp-files option is somehow ignored during parsing. > > I hope my description of problem is helpful enough for you to quickly > understand and fix those problems. > > > Regards > Tomasz Gajewski >

Re: [CEDET-devel] Cedet and Qt - problems with parsing headers From: Tomasz Gajewski <tomga@wp...> - 2012-12-06 22:02 Hi Eric "Eric M. Ludlam" <eric@...> writes: > It looks like you are working on the Qt sources, right? Could you tar > or zip up the smallest set of files that shows this behavior to email > me? Include your latest .el with ede-cpp-root project in it and > snippets that handle your semanticdb trick you described below, and > any other CEDET config you might have. Thanks. I have sent message with attachment directly to you (it was too big for this list). It contains minimal set of Qt includes and minimal .emacs file that shows problems I described previously. You will have to only update file paths. I use GNU Emacs 24.1.1. I started emacs with 'emacs --no-site-file' to be sure that nothing from my environment affects results. Cedet is from bzr trunk updated two days ago. > At that time there was a problem parsing the :spp-files when Semantic > was trying to parse the file you were in. If it is related to that, > it might even be that your 'delete the cache files' trick is causing > this problem. I think that deleting cache files can be related to first problem but I couldn't get defines from :spp-files working at all. > I'm hoping if I can figure this out, I can make a nice unit test out > of your sample code. > > As a side note, if you want to completely bypass semanticdb saving > files, you can use this in your .emacs file: > > (setq-default semanticdb-new-database-class 'semanticdb-project-database) > > This causes new tables to be a class that can't save, and thus, they > don't save. I use this in the test harnesses so that the environment > doesn't affect the running of the tests. Thank for this. But I hope I will not have to do it soon - I just wanted to extract repetable path to the problem. I can observe both problems on this restricted set of files. Regards Tomasz Gajewski >> To describe what is happening I've added some defines to ':spp-table' >> and others left to be found in files from ':spp-files'. >> >> I'm deleting contents of semanticdb-default-save-directory directory >> and starting emacs. I open 'qstring.h' file and the content is parsed >> without any of defines from :spp-table nor :spp-files. Output of >> semantic-lex-spp-describe does not contain them either. >> >> If I close and open 'qstring.h' again output of >> semanticdb-default-save-directory macros from :spp-table are in the >> output but not those from :spp-files. >> >> If I force emacs to reparse this buffer (by modifying contents and >> reverting without save) then I can see that macro definitions from >> :spp-table where interpreted properly. >> >> When after that I do: >> >> M-: (ede-apply-target-options) RET >> >> then output of semantic-lex-spp-describe contains all macro >> definitions. Those from :spp-table and from :spp-files. But the trick >> with reverting buffer makes semantic-lex-spp-describe reporting only >> macros from :spp-table. >> >> Calling 'bovinate' after 'ede-apply-target-options' shows output from >> parser: >> >> ... >> ("QString" variable >> (:type >> ("Q_CORE_EXPORT" type >> (:prototype t :type "class") >> nil nil)) >> nil #<overlay from 2484 to 30889 in qstring.h>) >> ... >> >> just as there was no Q_CORE_EXPORT macro even though the result of >> semantic-lex-spp-describe contains definition for this: >> >> Q_CORE_EXPORT nil >> >> First is that there is some race condition between parsing buffer (if >> it is first open file from project) and ede setting the environment >> for parsing (macro definitions). >> >> Second is that :spp-files option is somehow ignored during parsing.

Re: [CEDET-devel] Cedet and Qt - problems with parsing headers From: Tomasz Gajewski <tomga@wp...> - 2012-12-07 19:50 Hi Eric I have another question releated to parsing this qstring.h header: should I have to put configuration headers to :spp-files in ede project at all? Those headers are included from qstring.h header (not directly) but they are available. Shouldn't it work automatically? Can you explain how this is supposed to work and if included headers influence parsing current file and how? Regards Tomasz Gajewski

Re: [CEDET-devel] Cedet and Qt - problems with parsing headers From: Eric M. Ludlam <eric@si...> - 2012-12-10 03:45 On 12/06/2012 04:54 PM, Tomasz Gajewski wrote: > > Hi Eric > > "Eric M. Ludlam"<eric@...> writes: > >> It looks like you are working on the Qt sources, right? Could you tar >> or zip up the smallest set of files that shows this behavior to email >> me? Include your latest .el with ede-cpp-root project in it and >> snippets that handle your semanticdb trick you described below, and >> any other CEDET config you might have. Thanks. > > Attachment contains minimal set of Qt includes and minimal .emacs file > that shows problems I described previously. You will have to only update > file paths. > > I use GNU Emacs 24.1.1. I started emacs with 'emacs --no-site-file' to > be sure that nothing from my environment affects results. > > Cedet is from bzr trunk updated two days ago. Hi Tomasz, I spent a couple hours on your problem today. You example was helpful, and in researching it, I looked up my old test project, and found that it had a similar problem, so something broke from when I first got the spp-files feature working and today. I cleaned up how EDE interfaces with with the lexer, and uses the lexer's project spp table. That helped. I suspect this was also why my arduino macro's weren't working. I hope to test that theory soon. I checked in that batch of changes, and with it, your example then works the first time through. On the second restart of Emacs the tables for the headers with the macros are empty for me. It appears I still have a bit of work to do there. Anyway, I'm still working through the problem, and I think things are closer now with what I checked in to CEDET/bzr. Eric

Re: [CEDET-devel] Cedet and Qt - problems with parsing headers From: Tomasz Gajewski <tomga@wp...> - 2012-12-10 11:03 "Eric M. Ludlam" <eric@...> writes: > On 12/06/2012 04:54 PM, Tomasz Gajewski wrote: >> >> Hi Eric >> >> "Eric M. Ludlam"<eric@...> writes: >> >>> It looks like you are working on the Qt sources, right? Could you tar >>> or zip up the smallest set of files that shows this behavior to email >>> me? Include your latest .el with ede-cpp-root project in it and >>> snippets that handle your semanticdb trick you described below, and >>> any other CEDET config you might have. Thanks. >> >> Attachment contains minimal set of Qt includes and minimal .emacs file >> that shows problems I described previously. You will have to only update >> file paths. >> >> I use GNU Emacs 24.1.1. I started emacs with 'emacs --no-site-file' to >> be sure that nothing from my environment affects results. >> >> Cedet is from bzr trunk updated two days ago. > > > Hi Tomasz, > > I spent a couple hours on your problem today. You example was > helpful, and in researching it, I looked up my old test project, and > found that it had a similar problem, so something broke from when I > first got the spp-files feature working and today. > > I cleaned up how EDE interfaces with with the lexer, and uses the > lexer's project spp table. That helped. I suspect this was also why > my arduino macro's weren't working. I hope to test that theory soon. > > I checked in that batch of changes, and with it, your example then > works the first time through. On the second restart of Emacs the > tables for the headers with the macros are empty for me. It appears I > still have a bit of work to do there. Its great you've found time to investigate it. I've tried to check your changes but somehow it caused: Symbol's function definition is void: ede-cpp-root-project during processing .emacs. To exclude some other problem returned to version before your changes and it started to work again. Mayby it has something to do with my way of compiling. I just do: make clean-all bzr clean-tree bzr clean-tree --ignore make > Anyway, I'm still working through the problem, and I think things are > closer now with what I checked in to CEDET/bzr. Regards Tomasz Gajewski

Re: [CEDET-devel] Cedet and Qt - problems with parsing headers From: Vladimir Kazanov <vkazanov@in...> - 2012-12-10 12:09 Attachments: Message as HTML      I'd seen similar problems with ede-java-root-project today after recompiling latest cedet from bzr: the function is missing on load time, but available otherwise. Did not investigate yet. Changes in autoloads logic? On Dec 10, 2012 6:02 PM, "Tomasz Gajewski" <tomga@...> wrote: > "Eric M. Ludlam" <eric@...> writes: > > > On 12/06/2012 04:54 PM, Tomasz Gajewski wrote: > >> > >> Hi Eric > >> > >> "Eric M. Ludlam"<eric@...> writes: > >> > >>> It looks like you are working on the Qt sources, right? Could you tar > >>> or zip up the smallest set of files that shows this behavior to email > >>> me? Include your latest .el with ede-cpp-root project in it and > >>> snippets that handle your semanticdb trick you described below, and > >>> any other CEDET config you might have. Thanks. > >> > >> Attachment contains minimal set of Qt includes and minimal .emacs file > >> that shows problems I described previously. You will have to only update > >> file paths. > >> > >> I use GNU Emacs 24.1.1. I started emacs with 'emacs --no-site-file' to > >> be sure that nothing from my environment affects results. > >> > >> Cedet is from bzr trunk updated two days ago. > > > > > > Hi Tomasz, > > > > I spent a couple hours on your problem today. You example was > > helpful, and in researching it, I looked up my old test project, and > > found that it had a similar problem, so something broke from when I > > first got the spp-files feature working and today. > > > > I cleaned up how EDE interfaces with with the lexer, and uses the > > lexer's project spp table. That helped. I suspect this was also why > > my arduino macro's weren't working. I hope to test that theory soon. > > > > I checked in that batch of changes, and with it, your example then > > works the first time through. On the second restart of Emacs the > > tables for the headers with the macros are empty for me. It appears I > > still have a bit of work to do there. > > Its great you've found time to investigate it. > > I've tried to check your changes but somehow it caused: > > Symbol's function definition is void: ede-cpp-root-project > > during processing .emacs. To exclude some other problem returned to > version before your changes and it started to work again. > > Mayby it has something to do with my way of compiling. I just do: > > make clean-all > bzr clean-tree > bzr clean-tree --ignore > make > > > Anyway, I'm still working through the problem, and I think things are > > closer now with what I checked in to CEDET/bzr. > > Regards > Tomasz Gajewski > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Cedet-devel mailing list > Cedet-devel@... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > >

Re: [CEDET-devel] Cedet and Qt - problems with parsing headers From: Tomasz Gajewski <tomga@wp...> - 2012-12-10 20:52 "Eric M. Ludlam" <eric@...> writes: > On 12/06/2012 04:54 PM, Tomasz Gajewski wrote: >> >> Hi Eric >> >> "Eric M. Ludlam"<eric@...> writes: >> >>> It looks like you are working on the Qt sources, right? Could you >>> tar or zip up the smallest set of files that shows this behavior to >>> email me? Include your latest .el with ede-cpp-root project in it >>> and snippets that handle your semanticdb trick you described below, >>> and any other CEDET config you might have. Thanks. >> >> Attachment contains minimal set of Qt includes and minimal .emacs >> file that shows problems I described previously. You will have to >> only update file paths. >> >> I use GNU Emacs 24.1.1. I started emacs with 'emacs --no-site-file' >> to be sure that nothing from my environment affects results. >> >> Cedet is from bzr trunk updated two days ago. > > > Hi Tomasz, > > I spent a couple hours on your problem today. You example was > helpful, and in researching it, I looked up my old test project, and > found that it had a similar problem, so something broke from when I > first got the spp-files feature working and today. > > I cleaned up how EDE interfaces with with the lexer, and uses the > lexer's project spp table. That helped. I suspect this was also why > my arduino macro's weren't working. I hope to test that theory soon. > > I checked in that batch of changes, and with it, your example then > works the first time through. On the second restart of Emacs the > tables for the headers with the macros are empty for me. It appears I > still have a bit of work to do there. After Alex fixed autoloads I checked current behaviour and have a little different results than yours. It doesn't work for me after opening the file first time after starting emacs with cleared caches. Output of 'semantic-lex-spp-describe' doesn't contain Qt specific macro definitions. If I change something and revert buffer it works. And it is the case which didn't work yesterday. 'semantic-lex-spp-describe' returns complete list of macros. After starting emacs again (without deleting cache files) macro definitions are not found, like in your case, and again modifying buffer and reverting helps. Regards Tomasz Gajewski

Re: [CEDET-devel] Cedet and Qt - problems with parsing headers From: Eric M. Ludlam <eric@si...> - 2013-01-01 03:28 On 12/10/2012 03:51 PM, Tomasz Gajewski wrote: > "Eric M. Ludlam"<eric@...> writes: [...] > After Alex fixed autoloads I checked current behaviour and have a little > different results than yours. It doesn't work for me after opening the > file first time after starting emacs with cleared caches. Output of > 'semantic-lex-spp-describe' doesn't contain Qt specific macro > definitions. > > If I change something and revert buffer it works. And it is the case > which didn't work yesterday. 'semantic-lex-spp-describe' returns > complete list of macros. > > After starting emacs again (without deleting cache files) macro > definitions are not found, like in your case, and again modifying buffer > and reverting helps. I finally got to work on this some more. I was unable to find a graceful solution to this problem where EDE was loading and querying before Semantic was fully loaded. As such, it was short-cutting all the macro setup. So after trying to find a better solution for a while, I gave up and just stuck in some code to force semantic spp tables to be available so EDE could initialize it. I managed to verify the failure via an integration test and that test now passes with the simple change. As such, cpp-root project and :spp-files and :spp-table slots behaviors are now locked down. Huzzah! Eric

Re: [CEDET-devel] Cedet and Qt - problems with parsing headers From: Tomasz Gajewski <tomga@wp...> - 2013-01-01 14:48 "Eric M. Ludlam" <eric@...> writes: > On 12/10/2012 03:51 PM, Tomasz Gajewski wrote: >> "Eric M. Ludlam"<eric@...> writes: > [...] >> After Alex fixed autoloads I checked current behaviour and have a >> little different results than yours. It doesn't work for me after >> opening the file first time after starting emacs with cleared >> caches. Output of 'semantic-lex-spp-describe' doesn't contain Qt >> specific macro definitions. >> >> If I change something and revert buffer it works. And it is the case >> which didn't work yesterday. 'semantic-lex-spp-describe' returns >> complete list of macros. >> >> After starting emacs again (without deleting cache files) macro >> definitions are not found, like in your case, and again modifying >> buffer and reverting helps. > > I finally got to work on this some more. > > I was unable to find a graceful solution to this problem where EDE was > loading and querying before Semantic was fully loaded. As such, it > was short-cutting all the macro setup. > > So after trying to find a better solution for a while, I gave up and > just stuck in some code to force semantic spp tables to be available > so EDE could initialize it. > > I managed to verify the failure via an integration test and that test > now passes with the simple change. > > As such, cpp-root project and :spp-files and :spp-table slots > behaviors are now locked down. Huzzah! Great. It seems to work as expected now. Regards Tomasz Gajewski

1 message has been excluded from this view by a project administrator.