Policy for extragear / playground folders
Alexander Neundorf
neundorf at kde.org
Tue Sep 1 22:28:43 CEST 2009
On Friday 28 August 2009, Andreas Pakulat wrote:
> On 28.08.09 20:53:06, Michael Jansen wrote:
> > On Friday 28 August 2009 20:18:19 you wrote:
> > > On 28.08.09 17:18:47, Michael Jansen wrote:
> > > > I'm compiling quite a bit of kde with my own scripts. I prefer to
> > > > compile smaller packages for convenience. While doing that i noticed
> > > > we don't have a policy for directories like:
> > > >
> > > > http://websvn.kde.org/trunk/playground/devtools
> > > >
> > > > http://websvn.kde.org/trunk/playground/base/plasma/applets/
> > >
> > > Ok, so people working in there can do whatever they want.
> > >
> > > > Some of the directories in there compile standalone. Others do not.
> > > > Which leads to some frustrating compile sessions. As you can easily
> > > > imagine having the luck to checkout a plasma/applets version where
> > > > all those applets compile is rather rare.
> > > >
> > > > In devtools for example icemon and cmake do not compile standalone.
> > > > icemon depens on cmake too. Most of the kdevelop plugins compile
> > > > standalone.
> > > >
> > > > So i would like to make all of the subdirectories in there compile
> > > > standalone and remove everything but add_subdirectory from the base
> > > > dirs.
> > >
> > > I object. playground is for people to play around, there shouldn't be
> > > any rules they have to adhere to.
> >
> > ????!!!!!!??????
> >
> > I want to make it possible for other people to actualy look at the things
> > people play around with.
>
> If they want to look at something they can check out that directory and
> try to build it. If that fails they can bug the developer in question or
> try to find out for themselves.
>
> > Currently it's more or less impossible for some of the stuff there.
> >
> > And if everyone is allowed to do what he/she wants, shouldn't we make
> > every possible effort to keep their stuff apart? so that one developer
> > messing up it's code doesn't make it difficult to compile the other
> > stuff?
> >
> > It's currently impossible to compile icemon because it HAS TO BE COMPILED
> > together with the kdevelop4 plugins.
>
> Thats wrong. It just is not standalone. It expects you to create a
> builddir for devtools/ not for icemon as standalone. As far as I know
> thats perfectly fine, especially looking at devtools/CMakeLists.txt
> where someone took great care to add all kinds of stuff.
>
> > i don't get the association but it needs devtools/cmake and it's
> > CMakeLists.txt is not self contained.
>
> Sure not, the developer wrote the CMakeLists.txt in the expectation that
> you checkout devtools completely. I'm not aware of any rrule or policy
> forbidding that. Other modules in playground may do it the same way, I
> don't know.
>
> > But it is IMPOSSIBLE to do that. The controlflowgraph kdevelop plugin
> > adds the
>
> There's no need to scream.
>
> > FindGraphviz.cmake with
> > set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
> > ${CMAKE_SOURCE_DIR}/cmake/modules
> > ). That directory is in the controlflowgraphs source directory. Which
> > doesn't work when it is aggregated into devtools. Standalone it compiles.
>
> Right. Which is just fine as well, the plugins in
> kdevelop4-extra-plugins are meant to be self-contained and buildable
> standalone.
>
> > So much to the do what you want. IT DOESN'T WORK THAT WAY.
> >
> > The minimum policy has to be. Whatever happens: Make your stuff self
> > contained.
>
> I don't see why. There's no reason to enforce a developer to think about
> how to find KDE/Qt etc. when he just wants to start with a small thing
> in playground. Sure if he does go for extragear or one of the main
> modules this will need to change, but so far its _really_ easy to start
> a project in playground, with a policy that everything has to be
> self-contained you're making it harder.
I'm not sure I agree here.
Things in playground can break, being able to build them separately probably
makes it easier to work/use some of the stuff.
> > It would be much easier if this stuff would be standalone with some
> > convenience makefiles. The same way kdebase does it.
>
> Apparently that was never the plan.
Probably, but probably not because there was another plan, but because there
was no plan.
I would actually suggest that the directories below playground/<submodule>/
should be standalone-buildable, and maybe the CMakeLists.txt in the parent
directories might be removed (since it's supposed to be unstable unrelated
stuff, isn't it ?)
Alex
More information about the Kde-buildsystem
mailing list