It was introduced to get newer File Picker dialogs (i#70927)
but the special manifest file for that was not actually used for years;
LO 3.5 already includes a generic manifest file that is like any other
and probably has zero benefit over the manfiest that is embedded in
the soffice.bin binary anyway.
Change-Id: I0f41f10ecf26201043a8c9964cdfef95bc348eb8
- remove Package_readme, use generated files from WORKDIR via include
path
- Package_license and Package_files deliver to INSTDIR
- split up Package_odk_shared_readme to have extra Package for
generated files
- gb_Extension_LICENSEFILE_DEFAULT points to INSTDIR
Change-Id: I019d3431e30d982e887ae0000c755e0d61f98893
These dummy files were apparently added for i#73345 to prevent issues
from dpkg when some core-0[345] package was empty; these packages are
never empty nowadays.
Change-Id: I58f03677473a594f03a51d0440095bdf4a6ea3fd
- gb_UnoApi_get_target returns the files in INSTDIR
- stop using rdb files from OUTDIR
- remove gb_UnoApi_install
- remove pointless 2nd parameter of gb_UnoApi_UnoApi
- order-only dependency from gb_UnoApi_get_target to
gb_UnoApiHeadersTarget_get_target because INSTDIR .rdb is always outdated
Change-Id: Id418f75e9b38d6fe135b55eca2594c2624bc41cc
Using advertised shortcuts -- inspired by Intel AppUp Centre's
requirement -- was not a good idea after all. I revert this,
and I also revert the commit that actually disabled it in
default Windows builds.
This reverts commit aa2450cb51.
This reverts commit b40012bd6d.
Currently we ship a libucpftp1.so with NEEDED libcurl.so.4 but that file
is not actually in the instset, just a libcurl.so with SONAME
libcurl.so.4.
(regression in LO 4.0.0)
Change-Id: I3a194c83c408587dd83ed4c690aa381664040c6f
...as per #libreoffice-dev IRC:
Sep 19 10:32:24 <mst__> sberg, moggi why the hell is that thing named
"cppunit/cppunittester" and inside a subdir? it's obstructing my attempt to
put it in $(INSTDIR)/program
Sep 19 10:33:28 <mst__> (... and if you wonder "wtf does it have to do with
INSTDIR" you have never heard of awesome LibreOffice_Test installset.... not
that i would know who needs it :)
Sep 19 10:36:36 <sberg> mst__, it is in a subdir of solver/*/bin so that on
Windows it would not accidentally have picked DLLs next to itself instead of
the module-local DLLs it was supposed to test (back when we had module-local
output trees)
Sep 19 10:37:02 <mst__> sberg, ahh hysteric reasons then, /me renames it
Sep 19 10:37:55 <tml> mst__, if nobody you know uses LibreOffice_Test, just kill
it?
Sep 19 10:38:59 <sberg> mst__, tml, LibreOffice_Test was conceived by pmladek
and/or kendy, IIRC
Sep 19 10:40:31 * kendy does not remember anything about it :-)
Sep 19 10:42:17 <sberg> wasn't that something so users (or QA people?) could
easily run the smoketest against an installation, to see whether the
installation is any good at all, by installing that LibreOffice_Test alongside
the installation proper?
Sep 19 10:43:26 <sberg> mst__, ...and I'd unscientifically vote to kill it
Sep 19 11:34:23 <pmladek> mst__, sberg: I have created the LibreOffice_Test
package for one QA guy. He does not longer work on LO. I am not sure if anyone
else started to use it. So, I think that it can be killed.
Oct 17 18:18:07 <tml_> sberg: have you ever noticed that when you try to
actually run instdir/unxmacxi/LibreOfficeDev.app , the system actually tries
to run cppunittester inside the app bundle (it says so in the crash report)
(it crashes because cppunittester requires a specialized DYLIB_LIBRARY_PATH
apparently)
Oct 17 18:19:29 <tml_> I suspect that the system when cppunittester as part of
the build process is run from inside instdir (i.e. inside an app bundle) the
system "caches" this false knowledge, and thinks that the executable of the
app bundle is cppunittester...
Oct 17 18:19:36 <sberg> tml_, no, never noticed; with "run
instdir/unxmacxi/LibreOfficeDev.app" you mean calling "open
instdir/unxmacxi/LibreOfficeDev.app"? (I always call
.app/Contenst/MacOS/program explicitly)
Oct 17 18:19:52 <tml_> yes, I mean "open instdir/..."
Oct 17 18:20:53 <tml_> some googling tells me that at least years ago, the
CFBundleExecutable key in the Info.plist is ignored if it is manually changed,
so I guess similar caching of mapping between an app bundle and which
executable to actually run happens in this case
Oct 17 18:23:17 <tml_> and last year somebody even claims "And while on Mountain
Lion, CFBundleExecutable seems to be a no-op", which would be odd, surely
there must be widely used apps that have several executables inside the MacOS
directory; how would the system know which one to run when the app is run?
Oct 17 18:24:38 <tml_> hmm, apparently the code that handles this might be open
source even, http://www.opensource.apple.com/source/CF/CF-744.18/CFBundle.c
Oct 17 18:25:52 <tml_> some mention of "caches" there yes, my guesses might be
right
Oct 17 18:27:05 <tml_> if I cp -R instdir/unxmacxi/LibreOffice.app foo.app and
open foo.app, it works fine
Oct 17 18:28:33 <tml_> anyway, I guess it would be cleaner to have cppunittester
somewhere else even without this problem
Oct 17 18:37:09 <sberg> tml_, yes, IIRC having cppunittester in instdir was a
misguided mst decision, because that odd LibreOffice_Test product (that
pmladek said nobody needs any longer anyway) includes it; I think consensus
was to kill LibreOffice_Test and move cppunittester where all the other NONE
executables are, but looks like nobody executed
Oct 17 18:37:55 <tml_> ah ok, so mst should know what needs to be done? good, no
need for me to try to hack this now then
Oct 17 18:38:19 <sberg> tml_, I'll do the cleanup tomorrow, unless somebody
beats me
This removes smoketest/losmoketest et al along with the *_Test product, as they
seem to not make sense without it anyway. smoketest/Executable_libtest.mk
appears to be a test that could also be run during the build, and only ended up
in the *_Test product by accident, so I left it untouched for now.
Change-Id: I8024472c909fe0a885eb08ef4d3777f8a9e1f7c8
Clean up the horrible mess around unopkg.bin unopkg.com unopkg.exe and
soffice.bin soffice.exe and crashrep.com executables and associated
renaming via Packages in the desktop makefiles by simply using
RepositoryFixes to correct the names.
Change-Id: I4d3a549462cfa90a63d62b35db1b0407b25239f7
This is somewhat annoying since it requires re-introducing stupid
directories in scp2, but if the executables should be put in INSTDIR
directly then the Package_bin needs to go.
Change-Id: I893694c7f9d4cb5b9ef8ec4a3d30e08536223740
Those .jnilibs that are not needed as .dylibs (this includes those that are also
UNO components) are handled via RepositoryFixes.mk. The remaining one,
libjava_uno.jnilib is packaged as a symlink in instdir. Everything else is not
necessary and removed (including the venerable oddity macosx-create-bundle).
Change-Id: I34a1801b0733cdff885c1c72db16fa631c5d82ef
INSTDIR has everything that will be installed anyway, so ideally the
file search patch should only be INSTDIR + whatever is needed to get the
Package file lists; especially WORKDIR seems inappropriate there.
The exception is extension .oxt files which apparently are not in
INSTDIR; not sure what to do about those.
Change-Id: I2477c25ab9fcf953fae9c219e76c467e14729cda
This was added in commit 66eedcee02
but has apparently never actually been used in the bundled SDK
makefiles.
Change-Id: Ifa6cab95be6575ac26840250ad717d94e15bea66
The goal is to manage LibreOffice configuration centrally
in the enterprise. In Windows Server environment using
Group Policies is a common solution for configuration
management. Therefore it is required that LibreOffice can
read configuration data from Windows registry, too.
Windows registry is another configuration layer on the
top of normal xml based configuration.
For example the following registry setting:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.UserProfile\Data\o]
"Value"="Example Corp."
"Final"=dword:00000001
becomes the following in configuration:
<item oor:path="/org.openoffice.UserProfile/Data">
<prop oor:name="o" oor:finalized="true">
<value>Example Corp.</value>
</prop>
</item>
Change-Id: I2cdd83fc93922bf2806417bfd1b83f85cc926d4c
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
Version independent ComponentID in Component table of MSI means
that the GUID is calculated from the Component name only, the
PRODUCTVERSION is not concatenated to the name. Providing that
name is constant in all versions, the resulting GUID would be
the same e.g. for 4.0, 4.1, 4.2 etc. But what is it good for?
Faster upgrades maybe? But name can also change, we did not
pay attention to keep it constant. So in order to help scp2
cleanup, VERSION_INDEPENDENT_COMP_ID flag was obsoleted and
removed.
Change-Id: I8e1ee450524b02f07d0b0553f6b82d0321dbddcf
