starting to feature MDI

[Falk Brettschneider]

John Birch wrote:

> > > Also why
> > > did you create the libkdevelop* names? This again means that the
> > > makefiles cannot be regenerated.
> >
> > 1.) The old kdevelop.kdevprj restricts to use library names having the
> > _same_ name as the source subdir. :-( This means we would get:
> >       libdbg.so, libkwrite.so, libvc.so, ... which does not guarantee that
> > we wouldn't get naming conflicts with other KDE libraries also being
> > located in $KDEDIR/lib. (At least libkwrite.so). With the prefix
> > libkdevelop* we simply avoid that.
>
> Yes it is a restriction in kdevelop if kdevelop manages the libs - so we just
> change the dir name, this doesn't seem a big deal :-)

But then the change is done within the:
####### kdevelop will overwrite this part!!! (begin)##########
...
####### kdevelop will overwrite this part!!! (end)############

So I suppose changes made "by hand" will be overwritten, wont it?

>
>
> > 2.) The old kdevelop.kdevprj does not support such subdir structures like
> > qextmdi/include, qextmdi/src, qextmdi/res. :-(
>
> Not entirely - it means that kdevelop cannot _manage_ this structure. It can
> avoid it though...
>
> Another alternative is to change the dir structure of qextmdi in kdevelop.
> Are you really very keen to hang onto that structure given the way kdevelop
> works?

Sorry, only in case of emergency. I already have to care for a code copy in our company, for the QextMDI
cvs-server and in the qt-addons project as well. I have this structure to be equal in all those projects...
With different project structures I would lose the survey.

>
>
> > 3.) It seems there's no possibility to configure the subprojects. Only a
> > change from static to dynamic and vice versa seems to be supported. :-(
> > Some projects can need extra settings - where do I set them in such a case?
>
> Add them after the kdevelop managed stuff. But what settings are you talking
> about in this case? I have version number settings - is there more?

Maybe it's handleable.... But for instance libkdevelopqextmdi.so links against kpart in the defined
Makefile.am additionally

> but I suspect you'll want to do more before you've finished

Of course. :-) But if you want, you can also hack the project...

> a/

Agreed

>
> b/

Agreed.

>
> To me, both these points far outweigh the hassles we have in doing it and the
> hassles are not great even then. You're allowed to disagree, of course :-)
> but unless you are absolutely adament against it, I will fix this up so
> kdevelop can manage these libs (qextmdi excepted) In fact on my machine most
> of this has been done, I just have a bit of renaming left, but I'll leave
> this until I wake up again tommorrow.

Great. The problem is only: how can I get your features into 1.4 without getting my usuability-destructive
change, too? :-) Do you commit to the 2_1_1 branch?

>
>
> And besides these two points, it's just far easier doing it in kdevelop and
> that's always a pleasent surprise to me :-)

Cool, if we could improve it in that way... :-)

>
>
> jbb

See you,
F at lk



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«