Changing any of the Mac plist.in files that are part of
AC_CONFIG_FILES wouldn't automatically re-autogen and update the
generated non-in plists.
Change-Id: I135cb6d02a6996203f90221e361b0e826996486c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202263
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Tested-by: Jenkins
That build variant whose build could be triggered
e.g. by running
./gradlew assembleFullUIRelease
from `android/source` would fail to build for
a long time already, like this:
/home/michi/development/git/libreoffice-WORKTREE-android/android/source/src/java/org/libreoffice/ui/LibreOfficeUIActivity.java:189: error: cannot find symbol
final boolean bEditingEnabled = BuildConfig.ALLOW_EDITING && preferences.getBoolean(LibreOfficeMainActivity.ENABLE_EXPERIMENTAL_PREFS_KEY, false);
^
symbol: variable ALLOW_EDITING
location: class BuildConfig
In addition, it would be the default variant
used by Android Studio, so in order to get
a working build, it was always necessary to
explicitly switch to another variant first
(using "Build" -> "Select build variant").
Drop it altogether, since it's unused.
(It would include all of the .ui files
in the APK while the other build variants
explicitly specify what files to include.)
Change-Id: I0a6096ec69897eb57f41c512e88a4c1a848480ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187623
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
As otherwise if autogen.input contains a --with-distro-config=foo line
and if that distro-configs/foo.conf get changed, the build won't pick
up the changes unless autogen.sh is triggered manually, and that's not
what is intended/expected.
Change-Id: I81523572cedb953fff7cb69b8739fb1c76c9718a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181886
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
The Mac App Store expects the bundle identifier to be the application's
bundle identifier + "." + the extension name and the extension name
cannot have any period characters.
Change-Id: I8c2ee048dc52bec961e6d740edfd05cf3e11d631
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180257
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
when the user runs wsl.exe ./autogen.sh in a long path, the build
initially works OK, it will realize that the build is performed in the
source directory.
However if another run of wsl.exe ./autogen.sh is triggered by running
make (i.e. when configure.ac or some of the other files gets changed),
it was run with the shortened version of the path as the value for
SRCDIR, and comparing that with the pathname of the current directory
(which most likely was browsed to by using the long form) resulted in a
misdetection of the builddir != srcdir case, and autogen.sh did try to
create the necessary symlinks and <module>/Makefile and
external/*/Makefile files as if building in a separate build directory.
Especially the self-referencing symlink in the include dir then caused
some parts of the build (skia) to fail.
To avoid this problem, explicitly convert the path to its long-form.
This alone is not enough however to prevent the same issue occuring when
the user changed to the srcdir using the shortened form, then the
conversion would fail the same way (and while it is unlikely that the
user uses that path manually, launching a terminal via the
vscode-integration for example would also use the shortened form). So
also cd to the long form of BUILDDIR when running the automatically
triggered autogen.sh
Change-Id: I02c1ee7d302daa6062b6a049d924f40a49217e5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180511
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
This commit adds the DotnetTest gbuild class to build a unit test
suite using the .NET SDK and the NUnit testing framework.
Also adds a DotnetTest target for the net_ure module, with unit tests
for the Any type, as well as some minor changes to the Any type that
came about when writing the test cases.
Change-Id: Idbc08ac8f0736dd7355092dd1e69a5f1b4137c4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168956
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This commit adds the DotnetLibrary gbuild class to build a .NET assembly
using the .NET SDK.
Also adds an option to enable or disable building .NET components with
--enable-dotnet (default) and --disable-dotnet to the autogen script.
Also adds a net_ure/ directory for the updated .NET bindings, currently
consisting of the net_basetypes library.
Change-Id: I9256387a2463ff8476deee85d886c6b3dce8257b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166380
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Since these are produced by the build, they should also
be removed in the "clean" target.
Without this, Jenkins CI builds for the upcoming
Change-Id: Iddbe432519ab3040c83c0e977a584b51d3ef1e5b
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Dec 8 14:57:14 2023 +0100
android: Make the build fail on new lint warnings
were seen failing, despite the example file no longer being
part of the generated resources since
commit 1d7b1e2d40
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Nov 15 13:16:26 2023 +0100
android: Drop "More Info" item in "About" dialog
, but apparently the file was still lingering around
from previous builds.
Build failure/Lint error from CI build [1]:
> Task :lintReportStrippedUIEditingDebug
Wrote HTML report to file:///home/tdf/lode/jenkins/workspace/android_arm/android/source/build/reports/lint-results-strippedUIEditingDebug.html
> Task :lintStrippedUIEditingDebug FAILED
/home/tdf/lode/jenkins/workspace/android_arm/android/source/lint-baseline.xml: Information: 237 errors and 11 warnings were filtered out because they are listed in the baseline file, lint-baseline.xml
[LintBaseline]
/home/tdf/lode/jenkins/workspace/android_arm/android/source/res_generated/raw/example.odt: Error: The resource R.raw.example appears to be unused [UnusedResources]
Explanation for issues of type "UnusedResources":
Unused resources make applications larger and slow down builds.
The unused resource check can ignore tests. If you want to include
resources that are only referenced from tests, consider packaging them in a
test source set instead.
You can include test sources in the unused resource check by setting the
system property lint.unused-resources.include-tests =true, and to exclude
them (usually for performance reasons), use
lint.unused-resources.exclude-tests =true.
,
1 errors, 0 warnings (237 errors, 11 warnings filtered by baseline lint-baseline.xml)
FAILURE: Build failed with an exception.
This could also be reproduced locally:
After a
$ touch android/source/res_generated/example.odt
, the above error would on build, and neither `make clean`
nor `make android.clean` would remove the file and thus
fix the problem for subsequent builds.
Add removing the directory to the top-level and Android-specific
clean targets, so either of these commands now takes care of this.
[1] https://ci.libreoffice.org/job/gerrit_android_arm/33845/console
Change-Id: I91c83ce4ddb236d87d7c51f4dcce85e99aae0107
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160612
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
it's usually run bypassing all the dependencies & make parsing using
LD_LIBRARY_PATH=instdir/program make cmd cmd='ALL_LANGS="$(ALL_LANGS)" workdir/LinkTarget/Executable/pocheck'
but it doesn't hurt to also have it as a dedicated target
Change-Id: I742373eb0e4d87ea22c80da0dcaaba7116cd2937
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144250
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
while there is no builtin support to create a fat binary during the
actual build phase, we have a post-processing script that can merge two
separately built architectures into an universal binary one.
Thus enhance the makefile to support a more convenient way to build the
two archs without the need to manually move the package out of the way
to build the other arch.
1) assemble one architecture's package via
"make mac-app-store-package.prepare"
2) make clean and change targets in autogen.input to build for the other
architecture
3) build the other architecture and combine into universal binary and
also package into the final deliverable via
make mac-app-store-package.universal
(of course you can also use the .prepare target separately also in the
second build, and just mac-app-store-package will build the deliverable
for the current architecture like it did before)
Change-Id: I02c14e9b8c4f6e39d0d50cd3b4ffdd060b2d69bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141557
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
while most of the integration targets are meant to have a nice debugging
environment, others like the vim-ide-integration or also the vscode one
seek to provide a nice editing experience with code completion and code
lookup.
Ideally you'd be able to have the integration available immediately and
can use the editor while a build is running in the background. But from
a fresh builddir make vim-ide-integration (vscode-ide-integration) fails
because of the missing dependency. That dependency probably is optional
for the purpose of just providing a editing environment as opposed to
providing build-targets like the integration does for some of the other
IDEs, so I consider this commit more of a "good enough" workaround for
the time being.
Change-Id: I586445fed849d416fde9804a1e2a9c6ee0ed50eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141248
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
For providing coverage data of features in the LibreOffice code base,
here's a set of files with orthogonal, high-level ODF features like
bold & italic text, an image, a table in several variants etc.
Use `make coverage` or `make sw.coverage` to generate coverage data
for the entire code base, or subsets thereof.
Change-Id: If27f720e8728788c421e16a3abbc1cf39521a2fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139765
Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
the network.server entitlement is only needed when the sdremote is
enabled, and the bluetooth one only when the bluetooth part is built.
Also warn about bluetooth not being built because of obsoleted/removed
API. It was "silently" dropped before (lost in the flood of configure
output).
Change-Id: I38d83aa1132307b5b4b5d6dceba8f9020ffb2373
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136617
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
'make python3.all' was renamed to 'make python3.allcheck' (or use 'make python3.allbuild' to build without unit tests)
Change-Id: I5923382595deb952d3760a6173d40614e8ad5043
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133343
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Running 'make vs-ide-integration' fails since some recent change
(no idea if that was a cygwin upgrade, or some change in core).
Using 'verbose=t', the last lines are
make[1]: Leaving directory 'C:/lo/src/build'
cd C:/lo/src/core && C:/lo/src/core/bin/gbuild-to-ide --ide vs --make C:/cygwin64/opt/lo/bin/make
python3: can't open file '/cygdrive/c/lo/src/core/C:/lo/src/core/bin/gbuild-to-ide': [Errno 2] No such file or directory
make: *** [Makefile:495: vs-ide-integration] Error 2
It looks like python3 gets called by shell with the script path as
given in the comand line, according to shebang in the script; but
cygwin's python3 can't parse Windows-style path to the script, and
treats it as relative path from cygwin's current directory.
Just use true relative path to the script, to avoid the problem. We
cd to $(SRCDIR) anyway.
Change-Id: Idc25cc74f7a23f0e5733f0d10044986888b43ba1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129930
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
And just echo a rename info for the 'all' target and exit with
an error, so people will actually adapt. 'all' had been modified
to run 'allbuild' in the original commit anyway. And since there
is no toplevel 'all' target, this just seems consequent.
And .PHONY the new targets.
Also advertise "make help" a bit more at the end of configure.
Follow-up on commit d6496fce2e
("split gbuild's <module>.all to <module>.allbuild or .allcheck").
Change-Id: Ia74020375f0a024dc67ea37ae4b18655af9df084
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128490
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This is similar to the removal of the 'all' target in the past.
Using 'make vcl.all' is supposed to build the vcl module and all
its dependencies, the problem is that it builds also tests, which
means not only building and running the tests but also their
dependencies too, so 'make vcl.all' may in fact also build Writer
because a unittest depends on something there.
So now <module>.allcheck is the new name for that, and newly
there's also the (IMO actually useful) <module>.allbuild .
Change-Id: I55baa014a657783e641cee67948ee8fb062b1982
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128349
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This way we can get rid of the pre-generated locale data and the
special fuzzers target, which invokes a full gbuild make for
every prereqisite, always parsing the whole tree, taking ages.
This also reverts:
- commit d0780b21cf ("fix oss-fuzz
build") by adding epubgen and revenge dependencies.
- commit ff25d6a123 ("ofz#41602 fix
more build failure"), which shouldn't happen anymore since
commit d47628f287 ("don't want to
link to system static libs for DISABLE_DYNLOADING")
Change-Id: I3aed9ec62da507254b42e4e7470bae1097b4bc8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127031
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
to be consistent with the other ide integrations and to take care of the
extra step of running "make vim-ide-integration" to create the
compile_commands.json file required by the vscode integration.
Not using the autogenerated file created by configure directly might
also spare some users from having their own additions overridden
Change-Id: Ibb269197dc84f607b28ddad03adc919864e0c040
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126860
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
I have no idea, why this was omitted; probably just an oversight.
While a path as the target specifier looks strange to me, e.g.
ids like ComponentTarget_svx/util/svx, they work as expected.
Change-Id: I6dd4d382dddb8ad67cdd397db3b1c985c14cd948
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127023
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Build target was kept for backward compat in 'rework the default make
target', so lets retire it after 1.5 years.
Use 'make build' instead (which is since the default target anyway).
Change-Id: I93d5237dce2abf2536a4d847d79d33d5b6d6cec9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126362
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Ivan Vladimirovich Kuznetsov