Policy for extragear / playground folders

Andreas Pakulat apaku at gmx.de
Fri Aug 28 21:34:30 CEST 2009


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.

Andreas

-- 
Don't get stuck in a closet -- wear yourself out.


More information about the Kde-buildsystem mailing list