# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*- # # This file is part of the LibreOffice project. # # This Source Code Form is subject to the terms of the Mozilla Public # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/. # $(eval $(call gb_Library_Library,sdd)) $(eval $(call gb_Library_set_include,sdd,\ $$(INCLUDE) \ -I$(SRCDIR)/sd/inc \ )) $(eval $(call gb_Library_use_external,sdd,boost_headers)) $(eval $(call gb_Library_use_sdk_api,sdd)) $(eval $(call gb_Library_use_libraries,sdd,\ comphelper \ cppu \ cppuhelper \ sal \ sfx \ sot \ tl \ utl \ vcl \ )) $(eval $(call gb_Library_set_componentfile,sdd,sd/util/sdd)) $(eval $(call gb_Library_add_exception_objects,sdd,\ sd/source/ui/unoidl/sddetect \ )) # vim: set noet sw=4 ts=4: -LTS LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/sysui/CustomTarget_infoplist.mk
AgeCommit message (Collapse)Author
2019-04-25tdf#122244 Put InfoPlist.strings files at correct places on macOSStephan Bergmann
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>
2013-09-24Create a proper Info.plist for the OS X app bundle already in configureTor Lillqvist
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
2013-07-16gbuild: consolidate ULF copypaste in gb_CustomTarget_ulfex_ruleMichael Stahl
Change-Id: I0c5b68f6bc81c7c1c88be2cde42fc06949fff8e7