This reverts commit 3bfac473a1b1dfb2210ec07245e649697679bd83.
With Matus Kukan's work, which packs .ui files into .zip archives,
file count is reduced dramatically. Multiple .cab files won't be a
problem in theory, but unfortunately both .cab files had the same
disk id 'DISK1' and it caused problems with MSP patch generation.
since there are rpm-frontends that do their own version comparison that
is different from rpm itself.
Change-Id: Iddf38c14e7f48eec5d043de57e3404fcd9da24f7
debian packages don't cope with release number of 0, so use release 1
for debian master/dev-packages
Change-Id: Id91926322d13bddad3a39faccfee4e131d8956b0
get_Source_Directory_For_Files_From_Includepathlist already
has a special hack to find all the files in instdir so ideally it should
not be necessary to put these directories on the include path.
Clean up readlicense_oo to make that possible; also copying license.txt
as-is to LICENSE on Unix but first converting it on WNT is rather silly...
Change-Id: I95f30bc5e0b7ca73c50156a7ce0131640185778c
Reviewed-on: https://gerrit.libreoffice.org/6613
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
It is constant and can just be replaced by $(SRCDIR)/solenv.
Use BUILD_TYPE where it was used to check if config_*.mk is sourced.
Change-Id: Ib9d480c57194b6340093aa47776f8768df69b7d1
... it is an abbreviation of "Solar Version".
Since nobody can remember that:
remove OUTDIR OUTDIR_FOR_BUILD SOLARVER SOLARVERSION solarpath
and any mention thereof.
Change-Id: Idb3031c4f25a76ac05b22ec67e3ca3e1e8e512ad
Reviewed-on: https://gerrit.libreoffice.org/6515
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
- 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
...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
...instead of inconsitently having it depend on --enable-epm for some platforms
and having it always enabled on Windows. Only Android and iOS are presumably
still special and build any installation sets in their specific modules and
outside instsetoo_native.
One consequence is that for a non-Windows --enable-online-update
--without-package-format build, instdir's version ini-file contains an
UpdateURL that ends in just "?pkgfmt=" without an actual format identifier.
However, checking whether the update feature would actually work is difficult
for most such developer builds, anyway.
Change-Id: If14fcf0b2e612499811e8a6e067a854bda612c42
70c35265f517ef372cb739d4cc64499abf57a838 and
f89cce877cc0480e00ee226780dec887f9d0063a moved most stuff to instdir,
but forgot about epm and deb-builds. libgetuid.so that is needed to
build the debs is in instdir/ure/lib, but that wasn't added to the list
of include paths.
Change-Id: Iaf3f8cb2f6329dd66fe9f3862fd71f2037813d97
Reviewed-on: https://gerrit.libreoffice.org/6142
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Had been totaly broken by the recent changes. (Which is fine, it is
just an experimental hack anyway, I am not sure whether it will ever
be used in anger. Just a pet peeve of mine, I dislike seeing
libraries, configuration files, resources etc mixed together in one
"program" folder, especially on OS X, where the convention is to have
app-specific dylibs and frameworks in "Frameworks", and resource files
in "Resources". But this is not any requirement as such; there are
apps in the Mac App Store that blatantly "break" this convention.)
Basically, replace uses of gb_PROGRAMDIRNAME and
gb_Package_PROGRAMDIRNAME with more specific LIBO_FOO_FOLDER, which
for normal builds all expand to the same "program" anyway.
Change-Id: I16c2b3351caa00e251e229aafbccb8346042d3c1
After recent instdir changes the SCPZIP_REPLACE thing was not used any
more for Info.plist, so all the ${FOO} things were left in Info.plist
unexpanded with predictably wonky results, a non-working app.
Instead just expand it from the configure script.
While at it, use a correct CFBundleShortVersionString: only three
integers should be in that.
Also, hardcode FILEFORMATNAME as OpenOffice.org and FILEFORMATVERSION
as 1.0, and drop the "variables", as that is what those "variables"
*means*. They were used to refer to the OOo 1.0 formats. (It would
have been utterly wrong to define them as something else, like another
product name and a newer version number, in openoffice.lst, so
pointless to have them there.)
Drop the meaningless BUILDIDCWS.
Change-Id: I4030aa060b78e8b3fb812a6362869996e8db7d3d
Add more FOO_FOR_BUILD variables and some gb_Foo_for_build functions.
Get rid of gb_INSTROOT and gb_DEVINSTALLROOT, just use INSTROOT.
Change-Id: Iee531b02d14fae41edb68ad589a5dec829a60255
Windows installer on Windows XP cannot display messages, when the
installer database is encoded in UTF-8 and support for CTL languages
is not installed. This patch is a workaround, it disables the 'Remove'
button in Control Panel's Add or Remove Programs applet, so the user
has to choose 'Change', and has to uninstall LibreOffice with the
Wizard, which does not exhibit the problem.
Initially this bug was not expected, when we changed the enconding
from legacy codepages to UTF-8 - I would say irreversibly.
Then the severity of the bug was underestimated, because usually
uninstallation needs no user interaction, so it does not matter,
if the text is unreadable. However, in some circumstances
uninstallation needs to reboot the computer, and the user needs
to understand the question, whether to reboot now or later.
Change-Id: I7d6b4e82cbe4142d23c29313e43a90fa43944b2f
This used to be handled by the "LOCALUSERDIR $ORIGIN/.." line for
LibreOffice_Dev in openoffice.lst.in but that won't affect INSTDIR.
Change-Id: I1acd1ee7c08c98443e1cc425e1a6bb872d7c81f7
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
Introduced gb_INSTROOT, which is the same as $(INSTDIR) except for Mac OS X,
where it is $(INSTDIR)/LibreOffice.app/Contents. Most stuff ends up there (so
most occurrences of $(INSTDIR) have been replaced with $(gb_INSTROOT)), but SDK-
related stuff goes to $(INSTDIR)/$(gb_Package_SDKDIRNAME). (And
GeneratedPackage needed to be made more flexible, to allow for packages that go
into either of those two places.)
For Android and iOS, gb_INSTROOT probably still needs to be set.
The most obvious missing thing yet to make instdir work for Mac OS X is the
instdir/*/LibreOffice.app/Contents/ure/ vs.
instdir/*/LibreOffice.app/Contents/ure-link/ split.
Change-Id: I4478edd27b14c92c96d92d5169bdca3ec50d78f5
