| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
so no need for USE_FLATPAK, and just maybe there are some other
platforms that use this runtime as the distro info.
|
|
This file could also be in the "flatpak" repo instead. We'll see.
|
|
https://docs.flatpak.org/en/latest/conventions.html
|
|
Just remove OpenAL files and leave out FreeALUT's to avoid having
a custom prebuilt package and modifying autobuild.xml.
|
|
and OpenAL & FreeALUT dynamic libraries are only bundled if
USE_OPENAL is ON on Flatpak.
|
|
so upstream dullahan_host's rpath, which is meant to have
$ORIGIN/../lib, would correctly refer to the library dir (where
libcef.so is), without having to manipulate dullahan_host (cause
Flatpak SDK doesn't have patchelf). But Dullahan/CEF is still not
working on Flatpak just yet (LibVLC does, now, after I changed the
prebuilt package from Debian 13 binaries to Fedora 44 binaries,
where libvlccore links to libidn with the same compatibility
version.
|
|
Still uses prebuilt GLU, could be improved by using the glu shared
module.
Still uses prebuilt OpenAL, could be improved by separating the
ALUT dependency (which isn't available on the runtime) from it,
so we could use runtime's OpenAL.
Still uses prebuilt LibXML2, could be improved by separating the
Minizip & ColladaDOM from it (which aren't available on the
runtime) from it, so we could use runtime's LibXML2 but have
ColladaDOM built against it (and a still non-runtime Minizip).
Still uses FLTK 1.3, when I tried using 1.4, it still had linking
errors (might need to just add Cairo libraries to the
target_link_libraries).
VLC plugins are installed in vlc/plugins path relative to the vlc
& vlccore libraries, the way they are in the distro I got the
binaries from (Debian), cause I think it's the libraries that are
compiled with that path.
Still uses prebuilt dependencies in general, could be improved by
having them as modules to be built.
_FORTIFY_SOURCE needs to be skipped to avoid redefinition cause
Flatpak build system already defines it.
The conditionals for deciding installation paths need to be
reorganised to accomodate installation that doesn't require an
encapsulating namespace (because the installed files are already
encapsulated in the app sandbox).
The library directory naming scheme used here is lib64.
The libGLESv2.so & libvulkan.so.1 installed are still copies, not
links yet, because I'm still not familiar yet with the runtime
hierarchies (they might reside just in /usr/lib/x86_64-linux-gnu).
|
|
as they are available only for x86-64.
The PACKAGE=ON parity files are done too in case we switch it on
(and use CPack for macOS too, again) in the future.
|
|
|
|
This includes files of WebRTC, Discord, VLC & CEF and their media
plugins & resources.
This is so they won't clash just in case some other packages install
files with the same names in system library directories.
Furthermore, this seems to prevent Dullahan/CEF from breaking in
general.
The path to this encapsulating folder needs to be added as a runtime
path to especially dullahan_host & libmedia_plugin_cef.so so they can
find libcef.so etc, also for the viewer to find libllwebrtc.so &
libdiscord_partner_sdk.so. And that's why `patchelf` needs to be made
sure it's installed.
|
|
|
|
from zlib1.dll to z.dll
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
and boost-system is now header only.
|
|
|
|
|
|
Download DiscordSocialSdk-1.4.9649.zip
https://discord.com/developers/applications/1393451183741599796/social-sdk/downloads
to your ~/Downloads folder.
Add -DUSE_DISCORD:BOOL=ON to your cmake line.
The authorisation is triggered by selecting Help > Discord Social.
It seems that the user will need to do this every time they want Rich
Presence support on the viewer while using Discord.
The Discord app is still set to be a public client in the OAuth2 tab,
I'm going to try to make it work with the app set to be a confidential
client, next.
All Discord-related code are contained within one file, llstartup.cpp,
and other classes access it through some opaque layer, static functions,
otherwise we'd get these "duplicate symbol" linking errors.
|
|
|
|
This time for installation/packaging.
|
|
|
|
|
|
Turns out the CMAKE_BUILD_TYPE setting is necessary, otherwise it would
be built in RelWithDebInfo configuration.
Reorganise the contributors generation and general CPack settings in
indra/newview/CMakeLists.txt.
Running sed when cross-comping for Linux, on FreeBSD, doesn't need to
use Linux's sed, so no need for ${CMAKE_SYSROOT}/usr/bin prefix, this
way that section can be reused for Windows.
I still couldn't get CPack to make NSIS not use the version numbers as
part of the default installation destination.
Using TARGETS for installing llwebrtc would cause the .lib to be
installed too, which isn't necessary, that's why we use PROGRAMS.
contributors.txt still gets generated wrongly.
The executable icon is still SL's test icon.
ColladaDOM's failure to link to Boost throw_exception, from its use of
Boost Regex, is not fixed yet. I got to this stage by temporarily
removing the offending lines in daeURI.cpp (which are the lines where
Boost Regex is used).
|
|
This reverts commit 0b62583eb7dd6e193d5daa2e24646bbb9f3c74e5.
We have SDL for opening URLs now.
|
|
Shorter.
|
|
|
|
Gentoo uses lib64, just like Fedora, and has libexec too.
The necessary step to install dependencies is part of the ebuild script
now (tracked in another repo, ebuild.git).
One thing I forgot to mention on the commit in that ebuild repo is,
unzip.h is provided on Gentoo only by minizip, and not minizip-ng cause
somehow the (minizip) "compat" USE flag couldn't be turned on somehow,
and there was no "minizip" (without -ng) package on Gentoo, but it was
achievable by setting the "minizip" USE flag on the zlib (again, without
-ng) package.
The queue header inclusion is needed cause its absence would cause the
compiling to fail on Portage (though it compiled when building the
viewer manually without Portage).
Also, using the prebuilt Meshoptimizer caused some linking errors when
using Portage (though, again, it linked when building the viewer
manually without Portage), hence Meshoptimizer is built from source as
part of the CMake configuration on Gentoo, differing from fellow Linux
distros.
Now Collada DOM, firstly the unpack destination directory is moved to
inside the build directory now, to make it uniform with other 3rd-party
files, just for less confusion. Secondly, since the patching that takes
effect is the one done by Portage, it would kill the process when there
are offending failed patchings (ones that generate .rej, reject files),
and they are the vcxproj patchings which aren't used anyway. Thirdly,
the hash checking on the downloaded file, that would fail anyway since
Portage doesn't allow any downloading that isn't part of the ebuild,
unfortunately has to be skipped so the emerge process wouldn't be killed
just because of it. Ebuild has its own sum checking (though this means
this particular file is not checked on other platforms, but other files
aren't checked either anyway yet).
Last but not least, the XDG Application category is removed because it's
considered deprecated by Portage, though not fatal, but the viewer is
already shown well in the Internet (Network) submenu anyway on unix
desktops.
|
|
|
|
Some builders might just have their installation somehow customised to
have both.
|
|
|
|
as in Arch, there's really no /usr/libexec.
|
|
|
|
https://megapahit.com/show_bug.cgi?id=5
|
|
I've tried using FMOD instead, but CEF didn't work either.
At first I used crow-misia's WebRTC build but it would cause a
segmentation fault, but LL's build seems to break CEF.
Gotta find a way so CM's build doesn't crash the viewer.
PKGBUILD should be moved to indra/newview as an .in to be configured
by CMake for dynamic version numbers, and adjust the instruction
too to run makepkg -R from the folder where the generated PKGBUILD
will be.
|
|
|
|
|
|
The code is also moved to where it's relevant.
|
|
It didn't work before because the destination folder wouldn't exist
yet by the time it's configured, but CMake has been silent about it.
|
|
Somehow it wouldn't work when the libvlc dylibs linked by
media_plugin_libvlc were far in Frameworks, even with all the
linkages and VLC_PLUGIN_PATH set correctly.
Because of this, I had to make the libvlc files redundantly copied
(they're under 1 MB so we'll live with it) in llplugin just like
upstream for media_plugin_libvlc to link to instead, though it seems
the directory name can be anything, so I just let it be "plugins"
for installation convenience using CMake.
Also now the builder is assumed to not necessarily want VLC.app to
be installed in /Applications, though they would need to keep the
downloaded VLC disc image open.
|
|
and without having to rename the containing folder.
VLC streaming still hasn't worked (it used to) since using fixup_bundle,
since switching to FMOD, since switching from SDL to Cocoa, since
merging Maintenance B, so still no idea which of these is causing it.
|
|
|
|
|
