| Age | Commit message (Collapse) | Author |
|---|
|
until we've tried building another project, but based on this project's
liblinden. It's also because these headers would be in a separate -dev
Debian package.
|
|
Since we could use the dynamic versioning from the configuration phase
of CMake, the inclusion is put in BuildVersion.cmake.
Other CPACK variables are usually static so can be set when running
cmake.
CPack somehow doesn't pick up the DESTINATION values in ViewerInstall
(slplugin & libvlc too) from UnixInstall, so they're they're partially
hardcoded again there.
|
|
When cross-compiling, the host's /usr/local/include would be unsafely
included before. The problem with this was that it leaked other host
library headers unexpectedly, like Boost. The target compilation caught
some function from the host headers which of a newer version, and then
when trying to link to the target libraries, the function wasn't
available yet in the older version.
|
|
source for viewer 6.6.14.581101
|
|
# Conflicts:
# indra/llcommon/llsdserialize.cpp
# indra/llcommon/llsdserialize.h
# indra/llmath/llvolume.cpp
# indra/llrender/llgl.cpp
# indra/llxml/llcontrol.cpp
# indra/newview/llpanelnearbymedia.cpp
# indra/newview/llsceneview.cpp
# indra/newview/llselectmgr.cpp
# indra/newview/llstartup.cpp
# indra/newview/lltextureview.cpp
# indra/newview/llvovolume.cpp
# indra/newview/skins/default/xui/en/menu_viewer.xml
|
|
|
|
Only found out after using CMake 3.26 for Darwin.
It wasn't an error when using CMake 3.24.
|
|
Useful when cross compiling.
|
|
The alt mouse click to cam is broken for now on macOS,
but this is the path we've chosen.
|
|
This reverts commit d883a11567252d9a0baff653bb16c38817a7c21c.
|
|
|
|
Both keycodes and scancodes are now 32 bits, so the key type is
lengthened from U16 to U32.
|
|
|
|
|
|
|
|
|
|
|
|
Useful when installed as shared libraries, so other viewer executables
can share these libraries.
|
|
Streaming is not working yet, though. Until it's made sure that the
dynamic library and plugins needed are on the paths the executable is
expecting them to be.
|
|
On some platforms,
pkg-config --libs vorbis
might not necessarily imply -logg.
vorbisenc & vorbisfile need their own checks anyway.
|
|
|
|
X11 is still required too, that's why it's still added for linking.
On Darwin, SDL is disabled for now.
|
|
for now. Dictionaries should later be enabled when we have arrived at
the point where everything has run well that the next stage would be the
packaging for the distribution stage.
|
|
and at the same time escape use_prebuilt_binary commands in the file.
|
|
So far all of GTK2 dependencies flags, such as for Pango, Cairo, PNG16,
etc., seem to be implied by checking the gtk+-2.0 module alone, at least
on FreeBSD and Debian.
|
|
The module name to check with pkgconf is different, hence the special
treatment.
|
|
There are also several additional flags from running pkgconf that we
don't get from pkg_check_modules. At least 1 is needed later when
compiling llprimitive.
|
|
Since the CMakeLists.txt includes some same .cmake files as the viewer,
I think the project might as well be a part of the Linden libraries
code. And for now is put under llprimitive (might not be consistent, in
fact the opposite, with they way llplugin relates to slplugin), but I
think this way results the least change, and it still works.
The differences include:
- all files (common llphysicsextensions headers to be included by
library users and the stub implementation files) are put inside one
directory, and the CMakeLists.txt is adjusted accordingly;
- modernised CMakeLists.txt, so include_directories are now implied by
target_link_libraries;
- some file name fix;
- add_library is not explicitly set to STATIC;
|
|
The Meshoptimizer CMake files don't seem to be working right. On more
than one platform, they always conclude the package as not found.
Nevertheless, the library is typically installed in standard paths, that
no special paths need to be included for Meshoptimizer to be found.
Except on macOS (so far), as existing package managers don't have that
package yet, hence the /usr/local/include addition. It's a safe path to
include anyway on other un*x platforms.
|
|
The module name to check with pkgconf is different, hence the special
treatment.
|
|
for the same reason as GLH, but since the headers are expected to be
installed in the same directory as GLH (and GLEXT.cmake includes
GLH.cmake), we can skip any additional directory to look the headers for.
|
|
No package manager that I know of provide such package. So this one is
expected to be installed in /usr/local/include.
|
|
Some distros already include OpenSSL as part of the distribution,
that OpenSSL may not be provided with its .pc files, even though they're
available upstream.
|
|
The xmlrpc-epi package has no .pc or .cmake files. On some platforms,
the header and the library directories don't have special paths. On
GNU/Linux, at least on Debian, the headers are encapsulated in the
packages's own directory. On macOS, both MacPorts & Homebrew don't have
the package. On the other hand, Fink, that has the package, still
doesn't support recent versions of macOS as of this writing. So it's
very likely that on macOS, xmlrpc-epi is installed in /usr/local.
|
|
Calls to zlib-ng in the viewer code aren't prefixed. And in order to
build, the zlib-ng package needs to be configured with the ZLIB_COMPAT
option on. Some package managers may not have provided the option on, or
to turn that on, yet.
|
|
|
|
The necessary linker flags to link the required Boost libraries are
somehow not obtained from find_package. Passing boost_context,
boost_fiber, or so on to find_package didn't help getting the linker
flags either. Hence the manual listing of the Boost libraries to link.
|
|
On some platforms such as FreeBSD or MacPorts,
pkg-config --libs apr-util-1
already includes -lapr-1. But on APT, the apr-1 module needs to be
checked too.
|
|
|
|
It was set to the same value as PKG_CONFIG_MULTI_LOCAL_GUESS before.
That's why it couldn't find any package installed by the package manager
on a GNU/Linux distro.
|
|
Its use_system_binary implementation first tries to use pkg-config to
generate the necessary flags. But if it doesn't find the package, then
it will try to use find_package.
The USESYSTEMLIBS is also brought back again though only in 1 place, and
the name because it's the one still on the wiki page (the building the
viewer with Autobuild one), so the CMake variable is not totally new.
|
|
|
|
DRTVWR-577 (#232)
|
|
to resolve conflicts in installer_template.nsi
|
|
DRTVWR-577 (#232)
|
|
branch
|
|
|
|
|
|
With VS 2022 on Windows GitHub Actions runners, we can't build apr_suite at
all with the upstream .sln / .vcxproj files, so we had to switch to
"experimental" CMake support. However there's no CMakeLists.txt file for
apr-iconv, so the Windows package omits that library.
|
|
The package doesn't include that any more.
|
