Problem building 3.3.94

>turn off --enable-final and see if that helps.

Hmm, not sure where my replies are going... at any rate,
this fixed my compilation issue and I'm happy to say that
3.3.94 is up and running. On to using/testing it!

I guess the remaining question is why --enable-final made it
barf... see my other email with the attachments.

Thanks,
Nick

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 20.12.06 09:42:19, Nick Savoiu wrote:
> >turn off --enable-final and see if that helps.
> 
> I guess the remaining question is why --enable-final
made it barf... see my other email with the attachments.

Because --enable-final was ever and will ever be in a
"experimental"
state, because nobody really works on it.

If you want to strip down the resulting binaries to save
space use strip
for that.

Andreas

-- 
You will be awarded a medal for disregarding safety in
saving someone.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 20 December 2006 23:03, Andreas Pakulat wrote:
> On 20.12.06 09:42:19, Nick Savoiu wrote:
> > >turn off --enable-final and see if that helps.
> >
> > I guess the remaining question is why
--enable-final made it
> > barf... see my other email with the attachments.
>
> Because --enable-final was ever and will ever be in a
"experimental"
> state, because nobody really works on it.

Khm, enable-final used to work for the whole KDE for a long
time (on 
linux)... It helps a lot if you have enough memory and can
even show 
things that can be considered as bugs as global variables
using the 
same name. 

Unfortunately it IS broken when using unsermake, so I don't
use it 
anymore, but it was quite handy in the past.

Andras

PS: I'm not saying to fix KDevelop for 3.4 as there are
other places 
that need manpower, altough that would be the best thing to
do.

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

On 20.12.06 23:11:59, Andras Mantia wrote:
> On Wednesday 20 December 2006 23:03, Andreas Pakulat
wrote:
> > On 20.12.06 09:42:19, Nick Savoiu wrote:
> > > >turn off --enable-final and see if that
helps.
> > >
> > > I guess the remaining question is why
--enable-final made it
> > > barf... see my other email with the
attachments.
> >
> > Because --enable-final was ever and will ever be
in a "experimental"
> > state, because nobody really works on it.
> 
> Khm, enable-final used to work for the whole KDE for a
long time (on 
> linux)... It helps a lot if you have enough memory and
can even show 
> things that can be considered as bugs as global
variables using the 
> same name. 
> 
> Unfortunately it IS broken when using unsermake, so I
don't use it 
> anymore, but it was quite handy in the past.

Hmm, all I heard of it until now was that it breaks
completely fine
code.

And the case of the OP indicates this as well, just to
clarify the line
(187 in cppnewclassdlg.h) the compiler chokes about and its
surrounding
look like this:

,----
|184 	QPopupMenu *accessMenu;
|185 	QPopupMenu *overMenu;
|186 	CppSupportPart *m_part;
|187 	CodeModel *myModel;
|188 
|189 	// configuration variables
|190	QString interface_url;
`----

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.

Andreas

-- 
Today's weirdness is tomorrow's reason why.
		-- Hunter S. Thompson

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

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.o
rg
K Desktop Environment - http://www.kde.org
_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel