/binaryurp/

languages). Change-Id: Ic69907a066e9afe1d66045016ad6bf9d997c67d0 Reviewed-on: https://gerrit.libreoffice.org/75728 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> tdf#122244 Put InfoPlist.strings files at correct places on macOS 2019-04-25T11:27:14+00:00 Stephan Bergmann sbergman@redhat.com 2019-04-25T06:39:03+00:00 7a08bfeabe21193e04b9747a831653efcfc63190 Don't know how this got broken, presumably somewhere along the line from 01344a8ca57636ac87108c22f777a02fe6d963d5 "convert sysui to gbuild and add to tail_build" through 4430ace32a8dfd534d5e1c64ec7855edad11e5c4 "tdf#90753: AutoInstall more packages" to the current state, where a spurious bin directory containing InfoPlist_*.zip files containing (empty) InfoPlist.strings files is placed in instdir/ and in the root window of .dmg files. As discussed in the <https://developer.apple.com/library/archive/documentation/ General/Reference/InfoPlistKeyReference/Articles/ AboutInformationPropertyListFiles.html> "Localizing Property List Values" section, those InfoPlist.strings files shall apparently be placed into the Contents/Resources/*.lproj/ directories. (And the zip wrappers were presumably needed in the past to transport their payload to the proper places in the installation set, and are now obsolete.) The list of Apple language IDs for the *.lproj directories was already duplicated in Makefile.in (test-install target) and solenv/bin/modules/installer/simplepackage.pm (sub create_package). Ultimately those lists should all be consolidated. Also, mapping from our language IDs (see solenv/inc/langlist.mk) to the Apple *.lproj ones needs some fixing (e.g., from zh-CN to zh_CN), and it is not clear to me why the old code explicilty added en-US to the gb_WITH_LANG list of languages for which to generate InfoPlist_*.zip and InfoPlist.strings files (when that would presumably be the non-localized strings stored in Info.plist itself). But as mentiond, those InfoPlist.strings files are all empty anyway (which may be due to another bug?), so it shouldn't matter much---at least for now---what Contents/Resources/*.lproj/InfoPlist.strings files exactly are present in an installation set. Change-Id: Iaadce2375ed319928891bace44f9866622ec3084 Reviewed-on: https://gerrit.libreoffice.org/71277 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Don't know how this got broken, presumably somewhere along the line from
01344a8ca57636ac87108c22f777a02fe6d963d5 "convert sysui to gbuild and add to
tail_build" through 4430ace32a8dfd534d5e1c64ec7855edad11e5c4 "tdf#90753:
AutoInstall more packages" to the current state, where a spurious bin directory
containing InfoPlist_*.zip files containing (empty) InfoPlist.strings files is
placed in instdir/ and in the root window of .dmg files.

As discussed in the <https://developer.apple.com/library/archive/documentation/
General/Reference/InfoPlistKeyReference/Articles/
AboutInformationPropertyListFiles.html> "Localizing Property List Values"
section, those InfoPlist.strings files shall apparently be placed into the
Contents/Resources/*.lproj/ directories.  (And the zip wrappers were presumably
needed in the past to transport their payload to the proper places in the
installation set, and are now obsolete.)

The list of Apple language IDs for the *.lproj directories was already
duplicated in Makefile.in (test-install target) and
solenv/bin/modules/installer/simplepackage.pm (sub create_package).  Ultimately
those lists should all be consolidated.  Also, mapping from our language IDs
(see solenv/inc/langlist.mk) to the Apple *.lproj ones needs some fixing (e.g.,
from zh-CN to zh_CN), and it is not clear to me why the old code explicilty
added en-US to the gb_WITH_LANG list of languages for which to generate
InfoPlist_*.zip and InfoPlist.strings files (when that would presumably be the
non-localized strings stored in Info.plist itself).  But as mentiond, those
InfoPlist.strings files are all empty anyway (which may be due to another bug?),
so it shouldn't matter much---at least for now---what
Contents/Resources/*.lproj/InfoPlist.strings files exactly are present in an
installation set.

Change-Id: Iaadce2375ed319928891bace44f9866622ec3084
Reviewed-on: https://gerrit.libreoffice.org/71277
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
sysui: try to fix Mac instsets 2018-07-11T14:16:13+00:00 Michael Stahl Michael.Stahl@cib.de 2018-07-11T14:07:53+00:00 e50a5477fa5949716c38f0f0d7f7835f8b02b7c8 7c6ca00e61c42bb7c43cbb7a3203d8bad5c0ed0e broke the Mac build, because the files from infoplist Package have double "/" because of the empty path in the call to gb_Package_add_files. Change-Id: I3a72e8de0a8f2256b068a491231aaaa3d3b00b6e
7c6ca00e61c42bb7c43cbb7a3203d8bad5c0ed0e broke the Mac build, because
the files from infoplist Package have double "/" because of the empty
path in the call to gb_Package_add_files.

Change-Id: I3a72e8de0a8f2256b068a491231aaaa3d3b00b6e