creating the libio. All these libraries are always used together, so we can put them
together in one single library.
This save almost 500 kb of the size of the final library.
Change-Id: Ib32fec36cc4eb80ca646ce472c1f1bcdd98ac62b
Reviewed-on: https://gerrit.libreoffice.org/6567
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Only libraries (and similar for executables) built as Library need to be
registered; those built via ExternalProject are delivered by Project and
used via gb_LinkTarget_add_libs. This also means there is no need to
mangle the names in RepositoryFixes.mk.
Change-Id: Ib0b67f54e2eb6efdb0c454c9e2dd599ada229676
Reviewed-on: https://gerrit.libreoffice.org/6533
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
- stop copying the DLL to OUTDIR
- since that was the main reason for the separation between
CliNativeLibrary and CliNativeLibraryTarget, merge the targets;
the newly inherited variables are not expected to cause problems
- the Library remains in layer NONE; the derived CliNativeLibrary
is in INSTDIR
- hardcode target to URE bin dir for now, no immediate need for
multiple layers
Change-Id: I3bf4859e8c574f84d69eb43d12ddce0d34b5730c
...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
and disable for Mac until code is adjusted to compile
Change-Id: I48c69962ae5e59ae3bdd35d343deeeffdde6e903
Reviewed-on: https://gerrit.libreoffice.org/6160
Reviewed-by: Thorsten Behrens <thb@documentfoundation.org>
Tested-by: Thorsten Behrens <thb@documentfoundation.org>
Adds opengl canvas implementation - display-list-based, all
rendering done as textured geometry. Needs shader support.
Currently compiles and works on Linux, Mac should be ~easy to
add, win32 eventually.
Change-Id: Ibf3eb88d6a36a91b2960a3a6320d708160e4fc14
This needs more investigation to find proper solution but the problem is
probably that URE/bin/cli_cppuhelper.dll is not signed by "sn.exe".
Change-Id: I318293603be838c41d09791136697de74091d37d
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
Putting it in a subdirectory on solver is no longer necessary since
python3 started delivering to INSTDIR, so lose the crazy naming.
Change-Id: I17e924e5d872768a64f6a3112f1294f3def7120e
... and put it in OOO layer since it's used by the smoketest instset.
It was in subdirectory for hysteric reasons, to pick up libraries from
module local output directories in the dmake build system.
Change-Id: I73b66672b17ede52c03071eb2ddee1a23c059ea9
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
... because this is the time of day when one thinks, wouldn't life
simply be more awesome if there were a SHLXTHDL layer?
Change-Id: I02df8a8bf9d7d641ea060e2cfef6643fe2202353
It would not be necessary to mangle the
affine_uno_uno/log_uno_uno/unsafe_uno_uno library names in
RepositoryFixes.mk if they were simply named right in the first place.
Change-Id: I0fce919549764d2335c5501c1110878b8709fa09
We now load OpenCL library dynmically at run-time as needed. So there
is no build time dependency on any OpenCL implementations.
Change-Id: I214399060398a7c5e37b9a254147ccc2834e7866
...for checking compatibility with the reference rdbs. unoidl-check is no
longer based on the legacy registry format, but can process all the various new
UNOIDL registry formats. regcompare is still included in the SDK for now.
(gb_UnoApi[Target]_set_reference_rdbfile now takes a non-empty sequence of rdb
files, any necessary dependencies of the final rdf file preceding it just like
it is required on the unoidl-check command line. Also, executing the
unoidl-check now properly depends on those rdb files.)
TODO: unoidl-check is too conservative for now and flags some changes as
incompatible that are not.
Change-Id: I92e4c69403c5e3fcb31707c98c65a2f509592dd4
...that can also generate an .rdb containing a specific set of entities,
intended to replace idlc (when reading directly from .idl source registries).
Change-Id: I630ce4640828979d7952dc24dbbef80a42a8140a
Second attempt, this time using a new type LIBO_LIB_FILE_BINARYTABLE
in scp2/macros.inc; for the resulting MSI file Orca lists the same
files in "Binary" table now.
Change-Id: I550ede75f16a46da9dd7377594aa28b7c06f0348
...(like is done for most of LO's non-URE libs already) to reduce likelihood of
name clashes, esp. on Windows where URE libs are found via PATH.
This introduces PRIVATELIBS_URE, and removes now-unused UNOLIBS_URE.
Change-Id: Ib95dd45f18de140a54e62d632dbf2239f83c232e
Various libaries were moved from PLAINLIBS to OOOLIBS but are referenced
with their full DLL file name in the code, e.g. "inprocserv.dll" and all
the MSI customactions; move them back to PLAINLIBS.
(mozbootstrap was also renamed but it shouldn't be a problem).
Change-Id: Ibca8f355f84008a525021a8d5484200a7e73758f
Pootle has many checks, but there are cases which are not covered.
Therefore I wrote a tool which checked three types of translation
errors:
1. Unique style names.
2. Unique spreadsheet function names.
3. Missing trailing '|' in Windows installer translation.
Usage: make cmd cmd=solver/*/bin/pocheck
It checks all languages and prints the report to stdout.
Change-Id: I89aad66ea41c0ebe4a6f45beaaf86afd1a6439cc
