summaryrefslogtreecommitdiff
path: root/shell/Package_senddoc.mk
AgeCommit message (Collapse)Author
2021-01-18mac: don't put script files into Contents/MacOS or framework-bin directoryChristian Lohmaier
Signing them as executable code would require external attributes, and those in turn break packaging into hfs+ dmg when building on apfs with Big Sur. It is not a new thing - the old Code Signing in Depth technote https://developer.apple.com/library/archive/technotes/tn2206/_index.html already reads: "Store Python, Perl, shell, and other script files and other non-Mach-O executables in your app's Contents/Resources directory. While it's possible to sign such executables and store them in Contents/MacOS, this is not recommended. […] Put another way, a properly-signed app that has all of its files in the correct places will not contain any signatures stored as extended attributes." The patch does exactly that for LO and the shipped python framework and adds symlinks for the moved files. Same applies for the Language pack applescript and the tarball - those are also moved into Contents/Resources Change-Id: Iab21e77b73f941248ca89c6e80703fdf67a1057c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109537 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2013-10-28gbuild: set Package default target to INSTDIRMichael Stahl
Change-Id: I2bc45e4ba63f5faaee7389bcd9d7b3f563503186
2013-09-25Start hacking --enable-canonical-installation-tree-structure back into shapeTor Lillqvist
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
2013-09-23Try to fix cross-compilationTor Lillqvist
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
2013-09-11Towards a working instdir for Mac OS XStephan Bergmann
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
2013-05-10More gb_PROGRAMDIRNAME clean upStephan Bergmann
Change-Id: I5af86e15bcb8958a680e7309f13d7a865f29d7a9
2013-05-04install scripts from shell using filelistsDavid Tardon
The FILELIST install method is really tailored to large sets of closely related files. It is not such a great idea to apply it just to move some unrelated files, delivered from a single module, out of $(OUTDIR), like here, because it requires splitting one Package to several to allow the files to be placed to different installation modules in scp2. The extra makefile increases the overhead needed to place a file into an installation set. We really need a better way to handle this... Change-Id: I2f271562d8773152e69d284b4fe8ae356dea0945