summaryrefslogtreecommitdiff
path: root/indra/newview/FixBundle.cmake.in
AgeCommit message (Collapse)Author
2024-07-28Build process' set up to link to Boost staticallyErik Kundiman
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.
2024-07-11Separate file for fixing Mac package dependenciesErik Kundiman
since the variable PACKAGE is not available to check any more by that stage.
2024-07-11Support for `make install` on macOSErik Kundiman
Just set CMAKE_INSTALL_PREFIX to the newview/Megapahit.app/Contents/Resources inside your build folder, and set PACKAGE to OFF.
2024-07-10`cpack -G Bundle` instead of `make install` on MacErik Kundiman
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.
2024-07-08Explicit on every permission desired for DullahanErik Kundiman
otherwise those executables couldn't be read and therefore couldn't be copied for bundle preparation, for example.
2024-07-07Not set var to shorten paths in install scriptErik Kundiman
Somehow it wouldn't work.
2024-07-07Links to SLPlugin's dependencies after installErik Kundiman
cause SLPlugin's Frameworks wouldn't exist yet before installation.
2024-07-07Link CEF & chmod a+x Dullahan execs after installErik Kundiman
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.
2024-07-05`make install` on macOS copies dep libs to bundleErik Kundiman
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