Also remove extended_core group. If something from there will be
needed, we will add it another way.
Currently only android/experimental/desktop/Makefile and
ios/CustomTarget_TiledLibreOffice_app.mk are known to do something.
Change-Id: I99936075e35ce98d684581838c0a19dccd83f942
Put cui and spl into extended_code and ignore the rest.
Also change DocumentLoader and LibreOffice4Android to use only
extended_core and writer as all the ios apps do, without knowing what is
really needed there.
Change-Id: Ic6a256ea47cc96132c0e7658d6ef2838b295ca71
It still seems to work for me.
Probably we do not need more components, but it's small enough for now.
Also add uui into 'core' group.
Change-Id: Ifadea8aa819ed17bbd021a0fa2373e6287e06446
The executable of the LibreOffice app (which as such at the moment
doesn't work, since the tiled rendering changes) is built using
gbuild, and thus we can't generate the native-code snippet in the
CustomTarget that builds the app bundle, but need it already when
building the executable. This is one wayt to handle that.
Change-Id: Ifdab40c970e93b1f2608cefc637df8a8e5396efe
If the link targets are not in workdir then 2 different aspects are
needed: the previously used location relative to workdir's LinkTarget
dir (for all the misc. related targets), and the full target file.
Adding an additional parameter to all LinkTarget functions would be
quite annoying, especially since it would need passing through all the
gb_LinkTarget__use functions in RepositoryExternal.mk; instead encode
both into the linktarget itself, and modify the functions
gb_LinkTarget_get_target to return the target and all others to return
the workdir linktargetname.
- replace gb_Library_get_linktargetname with either:
* gb_Library__get_workdir_linktargetname
* gb_Library__get_linktarget_target
* gb_Library_get_linktarget
- similar for gb_Executable_get_linktargetname
- similar for gb_StaticLibrary_get_linktargetname
- similar for gb_CppunitTest__get_linktargetname
- add calls to gb_LinkTarget__get_workdir_linktargetname where needed
Change-Id: I917ad7957fee50ec2517a9f9cc9ff452c8d97d1b
No, it isn't any closer to being "ready" despite the name, but still,
using the current approach, it clearly isn't restricted to be just a
viewer.
Also drop the verbose LOViewer prefix from class and file names in it.
Change-Id: Ib4e8a31d6fa1b35169ee98cf2aa8f0f22957164c
