Removing some things from C++ parser

Hi,

I'm doing krazy fixes at the moment in languages/cpp I found
that there
are quite some files that are currently not compiled and
also not used
anymore (I think most of them are related to the deprecated
kdev
codemodel). 

Are there any objections against removing these files from
svn? After
all its cruft thats not going to be used anymore.

On a side note (this one's for Roberto I think): I'm
guessing the few
inlines inside the C++ parser are by purpose to make it
faster, right?
(just checking that a krazy exclude is better than
un-inlineing them)

Andreas

-- 
You will be misunderstood by everyone.

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

On Wednesday, 25. July 2007, Andreas Pakulat wrote:
> On a side note (this one's for Roberto I think): I'm
guessing the few
> inlines inside the C++ parser are by purpose to make it
faster, right?
> (just checking that a krazy exclude is better than
un-inlineing them)

I'd say, as the C++ language support is not public API
anyways, inlines can do 
no harm with respect to binary compatibility, and that's
what they made this 
check for, afaik.

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

On 25.07.07 22:39:46, Jakob Petsovits wrote:
> On Wednesday, 25. July 2007, Andreas Pakulat wrote:
> > On a side note (this one's for Roberto I think):
I'm guessing the few
> > inlines inside the C++ parser are by purpose to
make it faster, right?
> > (just checking that a krazy exclude is better than
un-inlineing them)
> 
> I'd say, as the C++ language support is not public API
anyways, inlines can do 
> no harm with respect to binary compatibility, and
that's what they made this 
> check for, afaik.

Thats not quite right. I'm talking specifically about the
c++ parser and
that one does expose a public API, including installed
headers.

I think the same is true for the duchainbuilder and
expressionparser
(although those two wouldn't need to provide shared libs
with public
API, they could be compiled into the plugin directly)

Andreas

-- 
Don't let your mind wander -- it's too little to be let out
alone.

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

Hi

Il giorno 25/lug/07, alle ore 23:10, Andreas Pakulat ha
scritto:

> On 25.07.07 22:39:46, Jakob Petsovits wrote:
>> On Wednesday, 25. July 2007, Andreas Pakulat
wrote:
>>> On a side note (this one's for Roberto I
think): I'm guessing the  
>>> few
>>> inlines inside the C++ parser are by purpose to
make it faster,  
>>> right?
>>> (just checking that a krazy exclude is better
than un-inlineing  
>>> them)
>>
>> I'd say, as the C++ language support is not public
API anyways,  
>> inlines can do
>> no harm with respect to binary compatibility, and
that's what they  
>> made this
>> check for, afaik.
>
> Thats not quite right. I'm talking specifically about
the c++  
> parser and
> that one does expose a public API, including installed
headers.

please don't install the headers. Nothing (or very little)
in the C++  
plug-in should be public. Just look at visitor.h, it is
stupid (and  
ugly) keep it BC.

ciao robe


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

On 25.07.07 23:34:54, Roberto Raggi wrote:
> Il giorno 25/lug/07, alle ore 23:10, Andreas Pakulat ha
scritto:
> 
> > On 25.07.07 22:39:46, Jakob Petsovits wrote:
> >> On Wednesday, 25. July 2007, Andreas Pakulat
wrote:
> >>> On a side note (this one's for Roberto I
think): I'm guessing the  
> >>> few
> >>> inlines inside the C++ parser are by
purpose to make it faster,  
> >>> right?
> >>> (just checking that a krazy exclude is
better than un-inlineing  
> >>> them)
> >>
> >> I'd say, as the C++ language support is not
public API anyways,  
> >> inlines can do
> >> no harm with respect to binary compatibility,
and that's what they  
> >> made this
> >> check for, afaik.
> >
> > Thats not quite right. I'm talking specifically
about the c++  
> > parser and
> > that one does expose a public API, including
installed headers.
> 
> please don't install the headers. Nothing (or very
little) in the C++  
> plug-in should be public. Just look at visitor.h, it is
stupid (and  
> ugly) keep it BC.

Ok, fine with me. I just thought there was a reason why the
C++ parser
is a shared lib, like making it usable for other apps,
without needing
to copy it.

That also means means basically we don't need the extra
shared libs in
the C++ part, so we could build 1 plugin instead of 1 plugin
that
depends on 4 different libs (or is it just 3?)

David: Do you mind if I do that change this weekend - would
mean having 1
CMakeLists.txt in the cpp folder, not sure yet how to do the
tests then,
either separate files or also in the main 1. If you think
this might
disturb you too much in your SoC I can postpone it after
that. (CC'ing
you as you said you don't get any list-mails)

Andreas

-- 
Your step will soil many countries.

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

Am Donnerstag, 26. Juli 2007 00:39:02 schrieb Andreas
Pakulat:
> On 25.07.07 23:34:54, Roberto Raggi wrote:
> > Il giorno 25/lug/07, alle ore 23:10, Andreas
Pakulat ha scritto:
> > > On 25.07.07 22:39:46, Jakob Petsovits wrote:
> > >> On Wednesday, 25. July 2007, Andreas
Pakulat wrote:
> > >>> On a side note (this one's for
Roberto I think): I'm guessing the
> > >>> few
> > >>> inlines inside the C++ parser are by
purpose to make it faster,
> > >>> right?
> > >>> (just checking that a krazy exclude
is better than un-inlineing
> > >>> them)
> > >>
> > >> I'd say, as the C++ language support is
not public API anyways,
> > >> inlines can do
> > >> no harm with respect to binary
compatibility, and that's what they
> > >> made this
> > >> check for, afaik.
> > >
> > > Thats not quite right. I'm talking
specifically about the c++
> > > parser and
> > > that one does expose a public API, including
installed headers.
> >
> > please don't install the headers. Nothing (or very
little) in the C++
> > plug-in should be public. Just look at visitor.h,
it is stupid (and
> > ugly) keep it BC.
>
> Ok, fine with me. I just thought there was a reason why
the C++ parser
> is a shared lib, like making it usable for other apps,
without needing
> to copy it.
>
> That also means means basically we don't need the extra
shared libs in
> the C++ part, so we could build 1 plugin instead of 1
plugin that
> depends on 4 different libs (or is it just 3?)
>
> David: Do you mind if I do that change this weekend -
would mean having 1
> CMakeLists.txt in the cpp folder, not sure yet how to
do the tests then,
> either separate files or also in the main 1. If you
think this might
> disturb you too much in your SoC I can postpone it
after that. (CC'ing
> you as you said you don't get any list-mails)
>
> Andreas

I probably won't be working on it in the weekend, so I don't
mind.

The question is how we do make the tests continue working.
Maybe 
static-linking them against the c++ plugin would be the
easiest way.

greetings, David

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

On 26.07.07 00:53:50, David Nolden wrote:
> Am Donnerstag, 26. Juli 2007 00:39:02 schrieb Andreas
Pakulat:
> > David: Do you mind if I do that change this
weekend - would mean having 1
> > CMakeLists.txt in the cpp folder, not sure yet how
to do the tests then,
> > either separate files or also in the main 1. If
you think this might
> > disturb you too much in your SoC I can postpone it
after that. (CC'ing
> > you as you said you don't get any list-mails)
> 
> I probably won't be working on it in the weekend, so I
don't mind.

Oh, cool (I actually expected the opposite answer 

> The question is how we do make the tests continue
working. Maybe 
> static-linking them against the c++ plugin would be the
easiest way.

Thats going to be a no-brainer: use different CMake
variables for all
"parts" and then the tests include their test +
the needed parts.
Something like this:

set(duchainbuilder_SRCS .... )
set(parser_SRCS ... )

kde4_add_unit_test(duchaintest $
$ ...)

Well, you get the idea.

Andreas

-- 
You have Egyptian flu: you're going to be a mummy.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 25, 2007, at 9:28 PM, Andreas Pakulat wrote:

> On 26.07.07 00:53:50, David Nolden wrote:
>> Am Donnerstag, 26. Juli 2007 00:39:02 schrieb
Andreas Pakulat:
>>> David: Do you mind if I do that change this
weekend - would mean  
>>> having 1
>>> CMakeLists.txt in the cpp folder, not sure yet
how to do the  
>>> tests then,
>>> either separate files or also in the main 1. If
you think this might
>>> disturb you too much in your SoC I can postpone
it after that.  
>>> (CC'ing
>>> you as you said you don't get any list-mails)
>>
>> I probably won't be working on it in the weekend,
so I don't mind.
>
> Oh, cool (I actually expected the opposite answer 
>
>> The question is how we do make the tests continue
working. Maybe
>> static-linking them against the c++ plugin would be
the easiest way.
>
> Thats going to be a no-brainer: use different CMake
variables for all
> "parts" and then the tests include their test
+ the needed parts.
> Something like this:
>
> set(duchainbuilder_SRCS .... )
> set(parser_SRCS ... )
>
> kde4_add_unit_test(duchaintest $ $ 
>  ...)
>
> Well, you get the idea.
>
> Andreas

I'd recommend having a shared library that contains all the
parser  
stuff which the tests can link against rather than pulling
in the  
sources for the particular things to test. You would also be
able to  
link the plugin against the shared library as well. There's
nothing  
saying that any installed shared library has to have public
headers,  
so we can just not install those and be ok.

- --
Matt


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFGqCNFA6Vv5rghv0cRArzNAJ49mUEb2LaSOFuCAwJw/xNwMv0v+ACf
TxjM
LBJlGp26kGf3mkw3R0eBwAM=
=QTqA
-----END PGP SIGNATURE-----

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

On 7/25/07, Matt Rogers <mattrkde.org> wrote:
> There's nothing
> saying that any installed shared library has to have
public headers,
> so we can just not install those and be ok.
I second that

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

On 25.07.07 23:29:57, Matt Rogers wrote:
> On Jul 25, 2007, at 9:28 PM, Andreas Pakulat wrote:
> > On 26.07.07 00:53:50, David Nolden wrote:
> >> Am Donnerstag, 26. Juli 2007 00:39:02 schrieb
Andreas Pakulat:
> >>> David: Do you mind if I do that change
this weekend - would mean  
> >>> having 1
> >>> CMakeLists.txt in the cpp folder, not sure
yet how to do the  
> >>> tests then,
> >>> either separate files or also in the main
1. If you think this might
> >>> disturb you too much in your SoC I can
postpone it after that.  
> >>> (CC'ing
> >>> you as you said you don't get any
list-mails)
> >>
> >> I probably won't be working on it in the
weekend, so I don't mind.
> >
> > Oh, cool (I actually expected the opposite answer

> >
> >> The question is how we do make the tests
continue working. Maybe
> >> static-linking them against the c++ plugin
would be the easiest way.
> >
> > Thats going to be a no-brainer: use different
CMake variables for all
> > "parts" and then the tests include their
test + the needed parts.
> > Something like this:
> >
> > set(duchainbuilder_SRCS .... )
> > set(parser_SRCS ... )
> >
> > kde4_add_unit_test(duchaintest $
$ 
> >  ...)
> >
> > Well, you get the idea.
> 
> I'd recommend having a shared library that contains all
the parser  
> stuff which the tests can link against rather than
pulling in the  
> sources for the particular things to test. You would
also be able to  
> link the plugin against the shared library as well.
There's nothing  
> saying that any installed shared library has to have
public headers,  
> so we can just not install those and be ok.

This is not just about the parser lib, but a general
problem. The thing
with installing a shared library is that whenever somebody
changes the
code in a BIC manner the version has to be increased (AFAIK
at least),
which might be forgotten easily. I'm wondering wether
there's a way to
tell cmake to not recompile the sources for the tests, which
IMHO is the
only benefit of using a shared lib for the parts of the
plugin.

Andreas

-- 
Abandon the search for Truth; settle for a good fantasy.

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