Problem building 3.3.94

[Nick Savoiu]

Hmm, if the code can be wrangled to compile with --enable-final then why not make it the default mode afterwards? Then any checkin that breaks it can be more easily identified?

Nick

----- Original Message ----
From: Andras Mantia <amantia at kde.org>
To: kdevelop-devel at kdevelop.org
Sent: Wednesday, December 20, 2006 2:43:34 PM
Subject: Re: Problem building 3.3.94


On Wednesday 20 December 2006 23:43, Andreas Pakulat wrote:
> Hmm, all I heard of it until now was that it breaks completely fine
> code.

It breaks more often, but helps to create cleaner code. ;-)

> And the file has a proper
>
> #include "codemodel.h"
>
> at the top. The -I switches of the OP look a bit lacking, i.e.
> ../../lib/cppparser is missing where codemodel.h resides. And the
> Makefile.am does add the include to INCLUDES.
>
> I really see no error in the code or the build-system files, from
> that I conclude (for myself, until someone proofs otherwise) that
> --enable-final breaks compilation.

I don't have too much time to spend on this issue right now, but from 
what I saw there seems to be some conflict between the headers. 
enable-final creates a .cpp file with a bunch of #include "...cpp" (for 
all .cpp files for the target). This also means that all #inclusions 
from the .cpp and the .h files will be in one single file. This will 
catch problems like using the same #ifdef SOMEFILE_H in two header 
files (usually a copy/paste error), which otherwise could go unnoticed 
unless somebody tries to use the two header files together. I checked, 
and here this isn't the problem. But it is still some conflicting 
issue, because if you just move around the #include statements in 
the "big" .cpp file (e.g always move the problematic file to the 
beginning) you will see that it compiles what did not compile before 
indicating that things go wrong because the files that were before 
include headers or contain codes which are conflicting with the 
codemodel.h.

And if you ask me, I think I have found the problem. ;-)

simpletype.h has an enum:
enum Repository {
  CodeModel,
  Catalog,
  StringList,
  Both,
  Undefined
};

CodeModel and Catalog are the same symbols as the CodeModel and Catalog 
class defined in the interface. This means everywhere you would use
#include "codemodel.h" (or "catalog.h")
#include "simpletype.h"

referring to CodeModel or Catalog classes will not work!

The fact that this not happened yet is pure luck (try to add a 
CodeModel test();
line to simpletype.cpp and you will see).

I keep my opinion that if a software build with --enable-final as well 
it is generally more cleaner.

And while looking at this issue I also found strange things like:
#include "codemodel.h"
in simpletype.h, when the CodeModel *class* is not used

or  in codemodel.h

using namespace std; (in a header file!)

class CodeModel; (when this is not needed as the class is defined some 
lines below and it is not used before).

I think an inclusion review would not hurt. ;-)

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
_______________________________________________
KDevelop-devel mailing list
KDevelop-devel at barney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel