| Age | Commit message (Collapse) | Author |
|---|
|
https://megapahit.com/show_bug.cgi?id=76
It seems like we have to use LL's Collada DOM 2.3.
Make sure minizip is installed on macOS.
It should be safe to uninstall your system Collada DOM package now.
The CMake arguments might have to be completed for non-Darwin
platforms in a next commit.
|
|
Somehow it wouldn't get signed using the previous way even though
that's pretty much how it was done in my script all this time, which
would work. So I just had to move it to the next execute_process,
and problem solved.
|
|
CMAKE_OSX_DEPLOYMENT_TARGET here, even though reset in Variables.cmake
with mmacosx-version-min, will be used as the hardened runtime version
when codesigning.
Instructions use 11 as that version, as the builder is assumed to be
building for arm64. When building for x86-64, you can replace all 11
here with 10.15.
The sudo in codesigning is required for builders on Apple Silicon whose
SIP is enabled, which is assumed to be the most likely case.
Credits to Cate (32a).
|
|
foreach, and execute_process' OUTPUT_VARIABLE just don't work in
installation phase SCRIPT.
|
|
|
|
JsonCpp isn't used any more and Boost is linked statically now, so
SLPlugin doesn't need to link to any Boost dynamic libraries upwards
(which are of an older version and are there because they're still
needed by Collada DOM).
I suspect links to non-existent files have been the cause of why
Gatekeeper just wouldn't identify the developer despite the fact
that Apple notarisation service would still accept the bundle and
various Apple's integrity (command-line) tools would still validate
the bundle too.
This commit also removes unnecessary linkage changes for the media
plugins.
|
|
Only libbrotlidec.1.dylib that is linked by some other library there
(libfreetype.6.dylib).
This commit also reindented 8 spaces to only 4 spaces.
|
|
since the app links to Meshoptimizer statically now on macOS.
|
|
This reverts commit 9268fdd5b99bb8e426e7c1232916dfd909039f96.
|
|
on macOS and at least the one directly. Collada DOM's Boost dependency
is still 1.76 in MacPorts' case, and that's why we still have Boost
filesystem and system dylibs in Frameworks. On the other hand, the
viewer codebase now really depends on newer Boost, in my case I can
use MacPorts' 1.81. I had to switch to static because Boost 1.81
filesystem crashed for not finding the implementation of something
declared using BOOST_FORCEINLINE in boost/filesystem/path.hpp.
I think I know why, now. Cause the filesystem dylib that eventually
got installed was the 1.76 one depended on by Collada DOM, so there
was a conflict, there. For now the temporary MacPorts solution for
this is to install boost181 with -no_static variant (notice the "-"
there, so the static libraries are built and installed too). The
rest is so hack-ish, I had to manually recreate Boost links pointing
to 1.81 ones, only the ones needed, and for the libraries, only the
static ones.
|
|
since the variable PACKAGE is not available to check any more by
that stage.
|
|
Just set CMAKE_INSTALL_PREFIX to the newview/Megapahit.app/Contents/Resources
inside your build folder, and set PACKAGE to OFF.
|
|
Root project finally renamed to Megapahit, which has a nice effect of
CPack: - Run preinstall target for: Megapahit
CPack: - Install project: Megapahit []
but it's really because CPack Bundle file couldn't be renamed via
CPACK_PACKAGE_NAME like on DEB, RPM, and FREEBSD.
CPack determines its own destination root folder, which is Resources
(I didn't find a way to set it to Contents).
fixup_bundle is now run on the .app deep inside CPack staging folders
so that the dependency copies will be included in the DMG.
|
|
otherwise those executables couldn't be read and therefore couldn't
be copied for bundle preparation, for example.
|
|
Somehow it wouldn't work.
|
|
cause SLPlugin's Frameworks wouldn't exist yet before installation.
|
|
otherwise fixup_bundle would try to fix DullahanHelper executables
when otool -L somehow can't find files that contain spaces in their
names. By postponing the chmod until after fixup_bundle is called,
fixup_bundle will ignore the DullahanHelper apps since they contain
no executables yet by that time.
Apart from that, trying to link to CEF would fail before installation
cause SLPlugin's Frameworks directory wouldn't exist yet.
|
|
I couldn't get CEF & Dullahan copied using this function.
fixup_bundle on SLPlugin.app was considered invalid, however, SLPlugin
itself gets install_name_tool changed but pointing to a non-existent
Frameworks directory that would be in the SLPlugin.app bundle.
We will have to create and fill such directory with links to the upper
(the root viewer app bundle Frameworks') library copies ourselves.
We wouldn't want fixup_bundle to successfully fill SLPlugin's Frameworks
with copies instead of links anyway.
See:
`man cmake-modules`
https://cmake.org/cmake/help/book/mastering-cmake/chapter/Install.html
|
