KDevelop lib BIC changes

Hi,

 Seeing the recent commit of Adam Treat to KDevelop (and the
fact that 
compilation fails, see the end of the mail), I would like to
suggest to 
keep the same policy for KDevelop libs as for kdelibs.
Shortly: keep BC 
until Monday, announce BIC changes in time and if possible
adapt the 
usage of applications (right now KDevelop and Quanta only)
to the new 
interfaces. This is to have the whole KDE svn in a
compilable state any 
time, as it was stated in the "New kdelibs policy
starting monday" mail 
from Stephan Kulow on core-devel.

Error message:
Building CXX object 
lib/interfaces/CMakeFiles/kdevinterfaces.dir/kdevconfig.o
/data/development/sources/kde-trunk/kdevelop/lib/interfaces/
kdevconfig.cpp: 
In static member function ‘static
KSharedPtr<KSharedConfig> 
KDevConfig::sharedStandard()’:
/data/development/sources/kde-trunk/kdevelop/lib/interfaces/
kdevconfig.cpp:49: 
error: ‘class KSharedConfig’ has no member named
‘extraConfigFiles’
/data/development/sources/kde-trunk/kdevelop/lib/interfaces/
kdevconfig.cpp:61: 
error: ‘class KSharedConfig’ has no member named
‘setExtraConfigFiles’
/data/development/sources/kde-trunk/kdevelop/lib/interfaces/
kdevconfig.cpp: 
In static member function ‘static
KSharedPtr<KSharedConfig> 
KDevConfig::sharedLocalProject()’:
/data/development/sources/kde-trunk/kdevelop/lib/interfaces/
kdevconfig.cpp:71: 
error: ‘class KSharedConfig’ has no member named
‘extraConfigFiles’
/data/development/sources/kde-trunk/kdevelop/lib/interfaces/
kdevconfig.cpp:83: 
error: ‘class KSharedConfig’ has no member named
‘setExtraConfigFiles’
/data/development/sources/kde-trunk/kdevelop/lib/interfaces/
kdevconfig.cpp: 
In static member function ‘static
KSharedPtr<KSharedConfig> 
KDevConfig::sharedGlobalProject()’:
/data/development/sources/kde-trunk/kdevelop/lib/interfaces/
kdevconfig.cpp:93: 
error: ‘class KSharedConfig’ has no member named
‘extraConfigFiles’
/data/development/sources/kde-trunk/kdevelop/lib/interfaces/
kdevconfig.cpp:105: 
error: ‘class KSharedConfig’ has no member named
‘setExtraConfigFiles’
make[2]: ***
[lib/interfaces/CMakeFiles/kdevinterfaces.dir/kdevconfig.o] 
Error 1
make[1]: ***
[lib/interfaces/CMakeFiles/kdevinterfaces.dir/all] Error 2


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
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Wednesday 19 July 2006 15:29, Andras Mantia wrote:
> Hi,
>
>  Seeing the recent commit of Adam Treat to KDevelop
(and the fact that
> compilation fails, see the end of the mail), I would
like to suggest to
> keep the same policy for KDevelop libs as for kdelibs.
Shortly: keep BC
> until Monday, announce BIC changes in time and if
possible adapt the
> usage of applications (right now KDevelop and Quanta
only) to the new
> interfaces. This is to have the whole KDE svn in a
compilable state any
> time, as it was stated in the "New kdelibs policy
starting monday" mail
> from Stephan Kulow on core-devel.
>

No, sorry, I won't force the (perhaps less than) half-dozen
people currently 
spending time on KDevelop to adhere to the BIC changes
policy that kdelibs 
does. However, KDevelop should always be compilable against
current trunk, so 
really, it's about keeping your copy of kdelibs trunk up to
date, and the 
people of kdelibs trunk following the deadline.
--
Matt


_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Thursday 20 July 2006 02:54, Matt Rogers wrote:
> No, sorry, I won't force the (perhaps less than)
half-dozen people
> currently spending time on KDevelop to adhere to the
BIC changes
> policy that kdelibs does. However, KDevelop should
always be
> compilable against current trunk, so really, it's
about keeping your
> copy of kdelibs trunk up to date, and the people of
kdelibs trunk
> following the deadline.

That was only part of the issue, and sorry for the noise,
indeed 
updating kdelibs helped. The other issue was discussed, so I
don't 
repeat here.
But saying that kdevelop compiles is wrong, as it still
fails due to the 
static library issue. 

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
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Thursday 20 July 2006 02:54, Matt Rogers wrote:
> No, sorry, I won't force the (perhaps less than)
half-dozen people
> currently spending time on KDevelop to adhere to the
BIC changes
> policy that kdelibs does. However, KDevelop should
always be
> compilable against current trunk, so really, it's
about keeping your
> copy of kdelibs trunk up to date, and the people of
kdelibs trunk
> following the deadline.

That was only part of the issue, and sorry for the noise,
indeed 
updating kdelibs helped. The other issue was discussed, so I
don't 
repeat here.
But saying that kdevelop compiles is wrong, as it still
fails due to the 
static library issue. 

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
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Thursday 20 July 2006 02:41, Andras Mantia wrote:
> On Thursday 20 July 2006 02:54, Matt Rogers wrote:
> > No, sorry, I won't force the (perhaps less than)
half-dozen people
> > currently spending time on KDevelop to adhere to
the BIC changes
> > policy that kdelibs does. However, KDevelop should
always be
> > compilable against current trunk, so really, it's
about keeping your
> > copy of kdelibs trunk up to date, and the people
of kdelibs trunk
> > following the deadline.
>
> That was only part of the issue, and sorry for the
noise, indeed
> updating kdelibs helped. The other issue was discussed,
so I don't
> repeat here.
> But saying that kdevelop compiles is wrong, as it still
fails due to the
> static library issue. 
>

only for you on x86_64. it compiles fine for me. I already
told you that you 
should add -fPIC to the CMakeLists.txt file to make it
compile for you.
--
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Thursday 20 July 2006 02:41, Andras Mantia wrote:
> On Thursday 20 July 2006 02:54, Matt Rogers wrote:
> > No, sorry, I won't force the (perhaps less than)
half-dozen people
> > currently spending time on KDevelop to adhere to
the BIC changes
> > policy that kdelibs does. However, KDevelop should
always be
> > compilable against current trunk, so really, it's
about keeping your
> > copy of kdelibs trunk up to date, and the people
of kdelibs trunk
> > following the deadline.
>
> That was only part of the issue, and sorry for the
noise, indeed
> updating kdelibs helped. The other issue was discussed,
so I don't
> repeat here.
> But saying that kdevelop compiles is wrong, as it still
fails due to the
> static library issue. 
>

only for you on x86_64. it compiles fine for me. I already
told you that you 
should add -fPIC to the CMakeLists.txt file to make it
compile for you.
--
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Thursday 20 July 2006 02:41, Andras Mantia wrote:
> On Thursday 20 July 2006 02:54, Matt Rogers wrote:
> > No, sorry, I won't force the (perhaps less than)
half-dozen people
> > currently spending time on KDevelop to adhere to
the BIC changes
> > policy that kdelibs does. However, KDevelop should
always be
> > compilable against current trunk, so really, it's
about keeping your
> > copy of kdelibs trunk up to date, and the people
of kdelibs trunk
> > following the deadline.
>
> That was only part of the issue, and sorry for the
noise, indeed
> updating kdelibs helped. The other issue was discussed,
so I don't
> repeat here.
> But saying that kdevelop compiles is wrong, as it still
fails due to the
> static library issue. 
>

only for you on x86_64. it compiles fine for me. I already
told you that you 
should add -fPIC to the CMakeLists.txt file to make it
compile for you.
--
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Thursday 20 July 2006 02:41, Andras Mantia wrote:
> On Thursday 20 July 2006 02:54, Matt Rogers wrote:
> > No, sorry, I won't force the (perhaps less than)
half-dozen people
> > currently spending time on KDevelop to adhere to
the BIC changes
> > policy that kdelibs does. However, KDevelop should
always be
> > compilable against current trunk, so really, it's
about keeping your
> > copy of kdelibs trunk up to date, and the people
of kdelibs trunk
> > following the deadline.
>
> That was only part of the issue, and sorry for the
noise, indeed
> updating kdelibs helped. The other issue was discussed,
so I don't
> repeat here.
> But saying that kdevelop compiles is wrong, as it still
fails due to the
> static library issue. 
>

only for you on x86_64. it compiles fine for me. I already
told you that you 
should add -fPIC to the CMakeLists.txt file to make it
compile for you.
--
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Thursday 20 July 2006 02:41, Andras Mantia wrote:
> On Thursday 20 July 2006 02:54, Matt Rogers wrote:
> > No, sorry, I won't force the (perhaps less than)
half-dozen people
> > currently spending time on KDevelop to adhere to
the BIC changes
> > policy that kdelibs does. However, KDevelop should
always be
> > compilable against current trunk, so really, it's
about keeping your
> > copy of kdelibs trunk up to date, and the people
of kdelibs trunk
> > following the deadline.
>
> That was only part of the issue, and sorry for the
noise, indeed
> updating kdelibs helped. The other issue was discussed,
so I don't
> repeat here.
> But saying that kdevelop compiles is wrong, as it still
fails due to the
> static library issue. 
>

only for you on x86_64. it compiles fine for me. I already
told you that you 
should add -fPIC to the CMakeLists.txt file to make it
compile for you.
--
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Thursday 20 July 2006 02:41, Andras Mantia wrote:
> On Thursday 20 July 2006 02:54, Matt Rogers wrote:
> > No, sorry, I won't force the (perhaps less than)
half-dozen people
> > currently spending time on KDevelop to adhere to
the BIC changes
> > policy that kdelibs does. However, KDevelop should
always be
> > compilable against current trunk, so really, it's
about keeping your
> > copy of kdelibs trunk up to date, and the people
of kdelibs trunk
> > following the deadline.
>
> That was only part of the issue, and sorry for the
noise, indeed
> updating kdelibs helped. The other issue was discussed,
so I don't
> repeat here.
> But saying that kdevelop compiles is wrong, as it still
fails due to the
> static library issue. 
>

only for you on x86_64. it compiles fine for me. I already
told you that you 
should add -fPIC to the CMakeLists.txt file to make it
compile for you.
--
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel