Proposal: new non-shipping module for examples

[Aaron J. Seigo]

On Thursday 02 October 2008, Alexander Neundorf wrote:
> On Thursday 02 October 2008, Aaron J. Seigo wrote:
> > On Wednesday 01 October 2008, Stephen Kelly wrote:
> > > Alexander Neundorf wrote:
> > > > On Wednesday 01 October 2008, Aaron J. Seigo wrote:
> > > >> i'd like to propose a new module in svn: kde-training-kit[2]
> > > >
> > > > How about using kdesdk for this ? It's also for stuff related to
> > > > development.
> > > >
> > > > Alex
> > >
> > > I was going to propose kdesdk for housing techbase tutorials code a few
> > > weeks ago, but didn't get around to it yet. It can be linked to and
> >
> > the reason i didn't suggest kdesdk was that:
> >
> > * it gets shipped as part of KDE core releases, so the code would either
> > not be part of the default build (which is part of the current problem)
> > or get installed on user's computers (not what we want). a major problem
> > here is that if it isn't part of the build, we don't get buildbot
> > coverage.
>
> I don't think that's the case.
> We can have a switch KDESDK_BUILD_EXAMPLES, which enables/disables building
> the examples together with the rest of kdesdk.
> We don't need (want) to have install rules for the created example
> binaries.

that's quite true for stand alone example apps, but it's not true for things 
like plugins which you can't load unless they are installed. 

that happens to account for 100% of the current examples in plasma =)

> But there shouldn't be a real problem adding rules for installing
> the source files instead.

i don't think we'd need that ...

> > * it would increase the size of the module for what's really not very
> > interesting code to most people
>
> I think we both don't know how much of the examples would be interesting
> for how many people.

given that the number of people who write code are a small fraction of the 
people who donwload our sources, and that the people who will use those 
sources to write code using KDE some fraction of those ... 

> I would see it as a nice complement to the tools
> useful for developing for KDE, also to have example code which helps
> developing for KDE.

many (and likely most) of these people will have installed kdesdk from 
binaries. so they'll be downloading something extra in most cases.

the kdesdk tarball is 4706KB compressed, and takes something like 38MB on 
disk. for what would amount to a few hundred KB of uncompressed source, that 
seems a little unfortunate.

kdesdk is also mostly made up of generic tools for development. it's not 
really a "KDE SDK" in the traditional sense; i guess we could turn it into one 
though ..

to me it seems a lot clearer to just have:

* a module with a clear purpose
* no extra baggage attached to it
* a name that says exactly what it is

people have proposed kdesdk instead, i've pointed out a few downsides to this 
(nothing earth shattering, of course) ... can someone highlight the negatives 
of having a separate module?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20081002/dd7646ba/attachment.sig>