Request for review: Okteta plugin 0.1.0 for KDevelop 4.0

Andreas Pakulat apaku at gmx.de
Wed Aug 18 12:01:49 UTC 2010


On 18.08.10 12:31:59, Aleix Pol wrote:
> On Wed, Aug 18, 2010 at 7:24 AM, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 18.08.10 00:23:07, Friedrich W. H. Kossebau wrote:
> > > Mardi, le 17 août 2010, à 22:28, Aleix Pol a écrit:
> > > > On Thu, Aug 12, 2010 at 11:11 PM, Friedrich W. H. Kossebau
> > > > <kossebau at kde.org
> > > > > wrote:
> > > > > now that Okteta 0.5.0 is released, also all the headers for the
> > Okteta
> > > > > libs are published for the first time, so that 3rd-party developers
> > can
> > > > > make use of
> > > > > these libs in their software. Well, also 1st-party developers :)
> > > > >
> > > > > Thus I just gave some polish to the Okteta plugin for KDevelop 4.0 I
> > > > > started
> > > > > at the Kate-KDevelop sprint in Berlin early this year. I think it is
> > > > > ready for
> > > > > a first release now. Find it at
> > > > > http://websvn.kde.org/trunk/playground/devtools/kdevelop4-extra-
> > > > > plugins/okteta/
> > > > >
> > > > > Now I wonder:
> > > > > What to do? :)
> > > > > Where (repo, folder) would the released branch of the plugin end?
> > > > > How/where do I develop the version for KDevelop 4.1?
> > > > >
> > > > > So could someone please review the code and help with adding it to
> > the
> > > > > official plugins (if accepted as such)? Millian, at Akademy you
> > showed
> > > > > interest to help with this, still possible? :)
> > > > >
> > > > > There is still one problem (but on KDevelop side):
> > > > > in the filesystem tool in the RMB menu all actions from plugins are
> > added
> > > > > once
> > > > > more if the menu gets shown, so by the time appear x times.
> > Alexander, at
> > > > > Akademy you said you have a fix for this, but I still see this with
> > what
> > > > > I get
> > > > > if I compile the kdevplatform 1.0 and kdevelop 4.0 branches.
> > Strangely
> > > > > enough
> > > > > the KDevelop (1.0.0, 4.0.0) I use here on (K)Ubuntu does not have
> > this
> > > > > problem. Will this be ixed in 4.0.2/1.0.x? Could I help?
> > > > >
> > > > > Some blog blabla for more background:
> > > > >
> > > > >
> > http://frinring.wordpress.com/2010/02/16/okteta-going-for-kdevelop-and-ka
> > > > > te/
> > > > >
> > http://frinring.wordpress.com/2010/07/27/akademy-development-catalysator
> > > > > /
> > > >
> > > > Since we don't want to have oktetalibs installed as a kdevelop
> > dependency,
> > >
> > > You mean both hard and optionally dependency?
> >
> > Even though Aleix is one of the maintainers, I disagree with him on
> > this. We already have an optional runtime-dep on kdesdk in kdevplatform,
> > so IMHO it would be ok to have an optional build-time dep on kdesdk in
> > kdevelop for the okteta-plugin. In particular because kdevelop is now in
> > 'extragear' (well, will be again once its on git.kde.org), so there's no
> > technical problem with that.
> >
> 
> Well, the main problem I see here is that the user/packager will never be
> sure which ones are the really important dependencies.

Uhm, thats the idea behind the macro_log_feature call in cmake, it can tell
the user that a dependency is missing, where to get it and what is going to
be disabled if not installing it. And packagers will simply install all
optional dependencies anyway for building (even if they later on split the
source package into multiple binary packages).

Personally, I've always made sure that all dependencies that I didn't know
I won't need are installed. 

Andreas 

-- 
You work very hard.  Don't try to think as well.




More information about the KDevelop-devel mailing list