There is no reason to use a custom project structure. The usual Android
project structure makes the development of new features easier using a
modular approach. Therefore, the logic of gradle files was divided into
different levels, gradle scripts was migrated to kotlin,
dependency definitions was moved into toml file.
No one java or kotlin file has been changed.
These changes based on:
1) Android build structure:
https://developer.android.com/build/android-build-structure
2) Migrate your build to version catalogs:
https://developer.android.com/build/migrate-to-catalogs
3) Migrate your build configuration from Groovy to Kotlin
https://developer.android.com/build/migrate-to-kotlin-dsl
Note: The source module has not been renamed to app (this is the usual
name for a top-level application subproject), because I currently do not
know what other changes will need to be made besides gradle scripts
(maybe in the Makefiles or in other) for a correct build. Additional
analysis required.
Change-Id: Ic11efdb51524e795b8c6e2605b6501d9699c525c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195939
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
See instructions in solenv/gbuild/Trace.mk . This generates a file than
can be viewed e.g. in the Chromium tracing view.
Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
...to select the experimental ...Editing... Android build variant. (Ignored
for non-Android builds, but using libo_FUZZ_ARG_ENABLE anyway, just in case.)
Change-Id: I670925ff358039e38edc29db69f48a78d484f133
Reviewed-on: https://gerrit.libreoffice.org/65077
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
current android-gradle plugin creates the apk in dimension/flavor/variant
(whatever you want to call it) specific directory
Change-Id: I5514fe53c5c8c556d194a0f06ad6167b0b1cc98e
move preparation tasks (creating assets/processing files) from the
makefile into the gradle script
This allows much easier integration into android-studio (just open
android/source with android studio after running make to compile the
native library)
Change-Id: I9a9d6832797c24a7e195a1c7954cd6d20f5a8496
LOAndroid3 is based of LibreOffice4Android project which uses
ant/make for building. By using LibreOffice4Android as the base,
the project creates a APK archive which has all needed files
to start LibreOffice in Android environment.
Change-Id: I697d5f727bdaf93e774144ad597d7081d2609908
Ivan Vladimirovich Kuznetsov