Removing some things from C++ parser
apaku at gmx.de
Wed Jul 25 22:39:02 UTC 2007
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)
Your step will soil many countries.
More information about the KDevelop-devel