This commit adds Package targets for the net_basetypes, net_uretypes
and net_oootypes libraries to install them into instdir/program/dotnet.
Also adds a LIBO_SHARE_DOTNET_FOLDER variable mirroring the
LIBO_SHARE_JAVA_FOLDER variable.
Change-Id: I28cdb2dac799bd72d11c3e550bba1a946db8b49c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170098
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
…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>
(An upcoming change will add an instset/update-settings.ini file containing that
value, but using a GeneratedPackage for a single file instead of a directory
seems unsupported, so it will use the hard-coded value and a plain Package
instead.)
Change-Id: I12ffef4db71ce36be9096df674588b39c660e4de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161545
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...and allow each of them to be left off, for debug purposes, even if that may
render the resulting --enable-online-update-mar feature non-functional.
This change tracked each item that was potentially read from the
--with-update-config ini file, and turned each of them into a new
--with-online-update-mar-... option. The only exception and remaining TODO is
bin/update/upload_build_config.py (called from Makefile.gbuild).
distro-configs/Jenkins/LibreOfficeLinuxUpdater.conf (which might well be dead)
set --with-update-config=~/updater.ini with an ini file of unknown content. So
that no items are silently missing if we ever resurrect that distro-config, I
set all of the new options to =TODO there for now.
Change-Id: I17a13e0d190a868436bac10c1b0a6675d8c704c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160622
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
This already was a requirement for Windows for a few years now, and make
4.0 was released nearly 9 years ago, and it has been used in LO's build
system since it has been added 11 years ago while it was only available
in prerelease versions of make, providing an alternative workaround for
systems that didn't have make built from cvs… I guess it is finally time
to get rid of those workarounds and just require make 4.0 for everyone.
NOTE: reading files with the $(file …) function was only added with
version 4.2 of GNU make, and just using it without contents was added in
4.1, so those usages aren't supported
Change-Id: Ia1c2c86cfdbbd81f349bb9f7188299e16bdd155f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143910
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
This moves the classes from juh.jar and ridl.jar to libreoffice.jar
The goal is to have one single jar (and Java module, will be added later)
which developers can include to work with LO.
juh.jar and ridl.jar are kept as basically empty jars with libreoffice.jar
on its classpath to keep backwards compatibility.
This is a continuation of ae855bf481
and a preparation to have Java 9 module support.
Change-Id: Ifbbfb97f60373d14256e62ae3122913bd17d5bbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91930
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
jurt.jar and unoil.jar are kept as effectively empty jars, each with a
Class-Path: ridl.jar
in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or
without also loading ridl.jar) will still have access to their content.
Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi)
are not part of the URE, but are now made available by URE's ridl.jar. This
should probably not cause problems in practice.
At least for now, we seal exactly those packages in ridl.jar that were
originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now,
but that would be mildly incompatible, as it would prevent 3rd-party code from
introducing additional UNOIDL entities in the relevant namespaces (even if that
is something we do not want 3rd-party code to do anyway).
However, some JunitTest_jurt_* define classes in those sealed packages. In the
past they got away with that by using gb_JunitTest_use_jar_classset,*,jurt.
Instead they now need to gb_JunitTest_use_jar_classset,*,ridl and drop the
gb_JunitTest_use_jar,*,ridl. But the former only makes available the classes
that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the
UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the
udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests
get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use
gb_JunitTest_use_jar_classset,*,jurt but don't seem to acutally need it; lets
leave that for a follow-up clean up.)
As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/.
Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a
Co-authored-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
- in soffice.ini (sofficerc) the entry "CrashDumpEnable" default is "true"
- when false then the Dump.ini and the dump-file are not written
- when the switch --disable-crashdump is set, then the
switch "CrashDumpEnable" set to "false"
- when the entry "CrashDumpEnable" is missing, in this case is the
default true, too
- the checkbox under Options-General "Send crash reports to ..."
is deactive and shows off (only view, not change the config)
- when set the environment variable "CRASH_DUMP_ENABLE" to any char
then the switch "CrashDumpEnable=false" are overrules with true
and the Dump.ini and dump-file are write
Change-Id: I34e7795640eb95d111e18b0ad46ec67b2c126b19
Reviewed-on: https://gerrit.libreoffice.org/79273
Tested-by: Jenkins
Reviewed-by: Juergen Funk (CIB) <juergen.funk_ml@cib.de>
Using the make-file function, in this case no converting
this problem was introduced by switching to native Win32 make:
* Makefiles don't have any metadata to specify the encoding
* all of the Cygwin tools in the build system assume
everything is UTF-8 encoded
* Win32 make calls CreateProcessA(), which converts the
arguments from some so-called "ANSI" codepage to UCS-2
hence in commands invoked from make, the UTF-8 string is
erroneously interpreted as latin1 and converted to UCS-2.
Change-Id: Ibf3e573b07e7e2d9119e0ff7b4972d8065d84bea
Reviewed-on: https://gerrit.libreoffice.org/56272
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Michael Stahl <Michael.Stahl@cib.de>
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
Adaptions to UI, added more modes what the user
can do in SafeMode. Adapted locations to write
pack information and added places where to enter
SafeMode. Implemented basically all five
possible user choices
Change-Id: Ic5324a8f77ab434309e840949c3803e65a75c538
Reviewed-on: https://gerrit.libreoffice.org/29785
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
Saving configuration is now extended to three
basic modes, from just saving registrymodifiications
to adding user-defined config stuff to saving all
information in the user profile, additionally
configuration information for Extensions is saved.
Added configuration entries for this and tested
saving/restoring.
Change-Id: I79b09c37617803bf656826f76a7e3db79cda49ac
Reviewed-on: https://gerrit.libreoffice.org/29770
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
Added default values for SecureUserConfig values
to soffice.ini/rc which enable the mechanism,
enable by default and set a maximum of three backups
file in packed form. Added more handy flag for easy
decision to add compressed/uncompressed.
Change-Id: I5a624c09fec4e4278314e13fc5f693ac085d5e61
Failing to do this caused a mysterious uncaught exception in gengal,
with no explanation printed. This turned out to be caused by the
'CONFIGURATION_LAYERS: missing ":"' exception thrown in configmgr,
which was caused by the unencoded space confusing the parsing of the
CONFIGURATION_LAYERS thing.
Change-Id: I9c91819906c2e0dd434d9f96a04bc14c0e0408ed
This reverts commit 795c61e052.
<sberg_> but what is 795c61e052
supposed to help anyway? on all platforms, gengal should already get
URE_BOOTSTRAP set, either via redirectrc, or via
extendApplicationEnvironment()
<mst_> sberg_: so ... you mean that gengal.rc is actually unnecessary,
and that the problem was caused by a missing dep on
Package_instsetoo_native_setup ?
<sberg_> I'm pretty sure a missing gengal ini-file was a red herring
Change-Id: I50ebc360e0e5c75c16f8407cbac6a54753fca272
Reviewed-on: https://gerrit.libreoffice.org/20226
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
...to eventually support writing to dconf (see TODO).
Even when writing somewhere else, it may still be useful to read from the
current "user:" location, so a new convention was introduced to
CONFIGURATION_LAYERS types that support write-back:
- A leading "!" indicates that the layer is indeed used for write-back (probably
in addition to reading from it). For backwards compatibility (when users use
own settings of CONFIGURATION_LAYERS, instead of depending on the value in the
shipped fundamental ini-file), no prefix on the "user:" is now interpreted the
same as a "!" prefix.
- A leading "*" indicates that the layer is not used for write-back (but only
for reading from it).
Change-Id: I399cc7bfe927db50586834f9630c184aaa2153f2
...after 097292feab "Add HKEY_CURRENT_USER
registry integration" added "winuserreg:".
Even though changing from the exisiting "winreg:" to "winreg:LOCAL_MACHINE"
should be compatible, as it only ends up in fundamental.ini included in the LO
inst set, play it safe it keep treating "winreg" the same as
"winreg:LOCAL_MACHINE".
("url" is a misnomer now in configmgr's Components ctor, and should eventually
be renamed to something more accurate.)
Change-Id: Ifbcf3284d904490891642599468470d03547f92a
Reviewed-on: https://gerrit.libreoffice.org/17891
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Work in progress to allow integration of LO with
<https://wiki.gnome.org/Projects/FleetCommander>.
During configuration, dconf support is implicitly enabled when available on the
host (which is presumably only available on Linux). It is explicitly disabled
for TDF Linux builds for now, though, to avoid accidental dependencies of the
distributed installation sets on system dconf libraries.
A dconf layer is represented in the CONFIGURATION_LAYERS bootstrap variable with
type "dconf" and an empty URL. See the comment at the top of
configmgr/source/readdconflayer.cxx for the encoding of component-data in dconf.
All of this is still subject to change.
Change-Id: I2d08d81c8ea43ba4a99040a8882ae75b91bcfdb9
Reviewed-on: https://gerrit.libreoffice.org/16848
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Looks more logical to keep share/registry/'s xcscxu and res layers together.
* Lets the winreg code actually get executed by developers using the instdir/
instset. (Though it doesn't enable it during in-build tests, which typically
use their own CONFIGURATION_LAYERS settings.)
Change-Id: I49dd3a16773047f7d4dc372c60a58ada1970970a
...assuming the delayLoadHook in cli_ure/source/native/native_bootstrap.cxx is
no longer necessary and loading of cppuhelper from the program dir cannot fail
regardless in whatever scenario the cli_cppuhelper library itself is loaded.
Change-Id: I13f32b327bca4cce9780864f5e57cdad3860afe5
RMZeroFour