Parser issue? - Cont.
Aleix Pol
aleixpol at kde.org
Thu Nov 6 03:22:52 GMT 2014
On Mon, Nov 3, 2014 at 10:54 AM, Leon Pollak <leonp at plris.com> wrote:
> On Sunday 19 October 2014 20:37:00 Aleix Pol wrote:
> > On Sun, Oct 19, 2014 at 10:42 AM, Leon Pollak <leonp at plris.com> wrote:
> > > Hello, all.
> > > My previous mail (attached below) was not answered, so I continued to
> > > experiment.
> > > My experiments showed that none of the definitions made in the
> > > CMakeLists.txt
> > > file are not recognized by the parser.
> > > I have no idea why and how BUILD_PPC gets defined, no visible reason. I
> > > tried
> > > tochange its place to be the first - no influence.
> > >
> > > So, if nobody comments on this, I am going to fill report in
> > > bugs.kde.org...
> > > Thanks.
> > > -----------------------------------------------------------------------
> > > It seems that code browser/parser does not see correctly the
> definitions
> > > dependent on the variables defined in cmake file. I understand the
> > > complexity
> > > of the issue next to impossible.
> > > Still, may be kdevelop gurus may be so kind to suggest something to
> solve
> > > this?
> > > ---
> > > I have the same code for several different architectures. Thus I have
> > > build
> > > dirs for each CPU type named as BuildARM, BuildPPC, BuildPC, etc...
> > > My cmake.txt contains:
> > >
> > > #define build type XXX: /Projects/CSU/BuildXXX
> > > string(REPLACE "/" ";" LIST ${CMAKE_BINARY_DIR})
> > > list(GET LIST 3 BUILD_TYPE)
> > > if (BUILD_TYPE MATCHES BuildPC)
> > > add_definitions(-DBUILD_PC)
> > > elseif (BUILD_TYPE MATCHES BuildARM2)
> > > add_definitions(-DBUILD_ARM2)
> > > elseif (BUILD_TYPE MATHES BuildPPC)
> > > add_definitions(-DBUILD_PPC)
> > > elseif (BUILD_TYPE MATCHES BuildARM)
> > > add_definitions(-DBUILD_ARM)
> > > endif()
> > >
> > >
> > > There is also main system.h file which contains:
> > >
> > > #ifdef BUILD_PC
> > > #define BUILD_ARM
> > > #endif
> > >
> > > #ifdef BUILD_ARM
> > > #include "system-DVRM.h"
> > > #elif defined(BUILD_PPC)
> > > #include "system-TDR.h"
> > > #elif defined(BUILD_ARM2)
> > > #include "system-HDVR.h"
> > > #endif
> > > #if !defined(SYS_CPU)
> > > #error No CPU definition
> > > #endif
> > >
> > > (for accuracy - I debug some code in PC for different configurations,
> in
> > > the
> > > example - for ARM).
> > >
> > > What is unclear to me, that parser for some reason ALWAYS(!!!) thinks
> that
> > > only variable BUILD_PPC is defined! Independent of what configuration
> is
> > > chosen, it always thinks that BUILD_PPC is defined.
> > > I tried to delete all ~.cache and ~.ccashe directories, rebuild DB,
> > > recompile
> > > - nothing helps! Only BUILD_PPC is defined all the time.
> > >
> > > Is there any way to get out of this?
> > >
> > > Many thanks ahead.
> > > --
> > > Leon
> >
> > Hi Leon,
> > Sorry for taking so much time to answer.
> >
> > In general, the kdev-cmake parser should get this information from the
> > CMakeCache. Also this should work.
> >
> > Can you provide a (small) test project I can try with?
> >
> > Thanks,
> > Aleix
> Hello, Aleix.
> Now my turn to be sorry for the delay...:-)
>
> I created the test example with only my *.h files and "hello world"
> main.cpp.
> Please, find the example at:
> ftp://www.plris.com/pub/Test.tgz
>
> The example behaves a bit different, but still, not correct IMHO:
> None of the BUILD_XXX defines are not seen and SYS_CPU is unknown too.
> This is independent on which build type do I choose from the cmake menu in
> project's options.
>
> Can I be of any more help?
> --
> Leon
>
Hi Leon,
I've been trying to reproduce your bug and couldn't because your code
relies on the fact that the source code needs to be in
/Projects/something/BuildXXX.
I suggest you to:
1. point me to the bug report that describes this issue
2. look yourself at the output in stdout, you need to activate "kdevelop
(cmake support)" in kdebugdialog.
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop/attachments/20141106/607a9d1b/attachment.html>
More information about the KDevelop
mailing list