Request for review: Okteta plugin 0.1.0 for KDevelop 4.0

[Aleix Pol]

On Wed, Aug 18, 2010 at 3:25 PM, Milian Wolff <mail at milianw.de> wrote:

> On Wednesday, 18. August 2010 14:01:49 Andreas Pakulat wrote:
> > On 18.08.10 12:31:59, Aleix Pol wrote:
> > > > > > 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.
>
> I'm with Andreas here. Optional dependencies are perfectly fine and should
> not
> make a difference on whether to include something or not.
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>
Ok then, let's put it in KDevelop.

Does it work with 4.1?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100818/2d15a20f/attachment.html>