RFC: Turning flag TINY into ACTIVEONLY, move Author to toplevel dir
Inge Wallin
inge at lysator.liu.se
Tue Feb 19 21:07:46 GMT 2013
On Tuesday, February 19, 2013 21:58:10 Friedrich W. H. Kossebau wrote:
> Am Dienstag, 19. Februar 2013, 11:55:39 schrieb Jaroslaw Staniek:
> > On 18 February 2013 23:31, Friedrich W. H. Kossebau <kossebau at kde.org>
>
> wrote:
> > > Am Montag, 18. Februar 2013, 10:17:35 schrieb Jaroslaw Staniek:
> > >> Hi Friedrich, thanks for the effort and explanation.
> > >>
> > >> Regarding the naming only: I think TINY is useful in general. It would
> > >> be a starting point to alternative GUIs and apps that are not in the
> > >> Active family but are have in certain aspects minimal or stipped-down
> > >> functionality. So I'd like to effectively see general name (such as
> > >> TINY) kept as it is.
> > >
> > > What are you thinking exactly of? And we still could add that once those
> > > alternative GUIs and apps pop up, no?
> > >
> > > This sounds like preparing for hypothetical use cases, without concrete
> > > examples (and thus defined needs). But there are schools which teach to
> > > better avoid that, as it only adds unneeded complexity and will usually
> > > not be fitting stuff that actually pops up. And life showed at least me
> > > those schools are based on heuristics ;)
> >
> > Well, KEXI_ONLY and KEXI_MOBILE is not hypothetical, we want to have
> > that targets too, e.g. for Windows and/or BB10/Android builds.
>
> "hypothetical" was slightly extreme and bad wording, I meant "maximally only
> planned, but not yet started", so unknown in the real needs.
>
> > I don't know how to split the build targets now but the need is pretty
> > clear to me.
>
> Not to me :) Because, how does TINY relate to KEXI_ONLY and KEXI_MOBILE?
> Problem here seems that the meaning of TINY is undefined (task: define all
> build parameters), so everyone might use that parameter for other purposes.
> Like has happened now with Calligra Active, where TINY was not really
> matching the usecase even (as it also limits the range of filters built,
> which surely is not wanted for CalligraActive, at least with the tablet
> version where the full set is wanted, just the UI should differ).
Well... not really. Since Plasma Active is a viewer only only the import
filters make sense. ...which suggests another build option: VIEWER.
But we need to be real careful here so we don't end up with a twisty little
maze of build options, all alike (1p for that reference).
> And as you said yourself the effective meaning of KEXI_ONLY and KEXI_MOBILE
> (how to split the build targets) is also yet to be defined. So any preparing
> for those needs is based on guessing, and thus should better delayed to
> when the needs are known, I argue.
The tricky part is which options are dependent on which other options. I
think that we may very well end up with something close to the Linux kernel
build system if we are not careful. Or perhaps that would be a good thing.
-Inge
> Cheers
> Friedrich
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel+
More information about the calligra-devel
mailing list