| Age | Commit message (Collapse) | Author |
|---|
|
Now that MacPorts' newest Boost version is 1.88.
|
|
The Debian version supported is 13 (trixie), because that's the version
I could install on my M1, hence the Boost default version is 1.83 & we
can use system's OpenJPEG 2.5.3.
Somehow CMake's FindOpenGL wasn't effective, but we can get around this
by setting the GL libraries paths when running cmake.
Debian aarch64 suffers from the same problem Fedora aarch64 had when
compiling libcurl, and it's assumed that it's Linux aarch64 thing.
When trying to build ColladaDOM when building the viewer, it couldn't
find Boost somehow, so building ColladaDOM is done in configuration
stage instead.
Upstream Variables.cmake is full of assumptions regarding architecture,
and ARCH is used in many places already for Debian/Ubuntu, so we have to
make sure ARCH is set with the correct value at the root level.
Pipewire on trixie is also too new, so it's cancelled here.
Some dependencies have the t64 suffixes on them, just like the currently
supported Ubuntu (because I guess 24.04 *is*, based on trixie).
The executable still crashes when launched on my M1, however, but we'll
commit the progress so far for now.
|
|
|
|
before using it for ColladaDOM library file, cause it seems that
ColladaDOM is the first one that gets built on Windows arm64 before
any other package gets installed and implicitly creating that folder.
|
|
in viewer linking stage on Windows.
throw_exception is user defined (it's not picking up its definition from
anywhere on Windows, at least when using vcpkg's Boost).
(Link target) ->
libcollada14dom23-s.lib(daeURI.obj) : error LNK2019: unresolved external symbol
void __cdecl boost::throw_exception(class std::exception const &)
(?throw_exception@boost@@YAXAEBVexception@std@@@Z) referenced in function
void __cdecl boost::re_detail_500::raise_runtime_error<class boost::regex_error>(class boost::regex_error const &)
(??$raise_runtime_error@Vregex_error@boost@@@re_detail_500@boost@@YAXAEBVregex_error@1@@Z)
[C:\Users\erik\Documents\Megapahit\viewer\build-mingw64_nt-10.0-19045-x86_64\newview\megapahit.vcxproj]
|
|
and make the if, else, & endif styles more consistent.
|
|
Turns out I couldn't repeat self-building ColladaDOM using SLv prebuilt
Boost successfully, because of the zlib, minizip, libxml2 header
directories search confusion, no matter how I tried tinkering with LL's
ColladaDOM fork CXX_FLAGS and/or EXTRA_COMPILE_FLAGS settings.
With vcpkg Boost, self-building ColladaDOM in the viewer CMake
configuration stage goes smoothly (compiling ColladaDOM on Windows could
take a while, though.. at least on my system).
|
|
Plus simplifying the SHARED to STATIC stream editing by not using the
global 'g' key, cause it's only 1 instance to edit.
For now, BOOST_CFLAGS & BOOST_LIBS are set to refer to SLv prebuilt
binary installation, along with its library suffix.
try_compile doesn't seem to "compile" it, but it does configure it, so
we just execute MSBuild.exe afterwards.
Last time I tried, it didn't finish building or didn't build
successfully, though.
So what I did is manually run MSBuild.exe on ColladaDOM's solution file,
and the next CMake configuration picked up the generated library,
renamed to be the same as expected when using SLv prebuilt one, so that
we don't have to adjust more lines for this, it has to be copied/moved
anyway, might as well rename it the same.
About the WIN32 definition stream editing, somehow WIN32 is not defined
in daeUtils.cpp, that it would fail at deciding which commands to
compile. I did try adding /DWIN32 to CXX_FLAGS but it ruined it for the
Minizip header directory search. So the hack is to just forcefully
define WIN32 in that file.
|
|
|
|
I happen to be using just Git Bash for convenience for running the
commands on the Windows build instructions, hence the build folder
pattern to be ignored from the result of running `uname -s` there.
The instructions omit the part where you install vcpkg and set the
VCPKG_ROOT environment variable, cause it depends on where you install
vcpkg to your liking, but the next commands will rely on that variable
being set correctly.
The CMake used here is MS VS 2022 Community Edition's one, since it will
know where the C++ compiler is.
$VCPKG_ROOT/downloads/tools/msys2/21caed2f81ec917b/mingw64/bin is where
pkg-config.exe can be found.
$VCPKG_ROOT/installed/`uname -m|sed 's/86_//'`-windows/tools/libxml2 is
where xmllint.exe can be found (from libxml2[tools]).
PKG_CONFIG_LIBDIR and PYTHON environment settings are pretty
self-explanatory.
The flags set on LL_BUILD are now for Visual C++ and not MinGW(64)'s GCC
or Clang any more, and copied from most of the flags in the variables
file from LL's build-variables repo.
vcpkg's apr & apr-util packages don't seem to install their .pc files,
hence the manual target_include/link_directories/libraries settings,
relying on some automatically generated INTERNAL CMake variable called
prefix_result. vcpkg's Boost needs the same treatment, plus some suffix.
We still use LL's prebuilt libs for OpenSSL, libcurl and WebRTC.
Actually too for ColladaDOM for now, but we prepare Windows ColladaDOM
self-building for later.
For GLM and Meshoptimizer too, it's just the checking that's skipped
otherwise it would fail (but the vcpkg packages can be used).
Visual C++ doesn't recognise the no-deprecated-declarations compile
option.
On Visual C++, the macro to denote x86-64 seems to be _M_X64 (if not
added there, it would try to find sse2neon :))
We still aren't using Autobuild here for Windows either, hence the
FALSE-d viewer_manifest.py based file bundling.
|
|
but the fact that we keep on using as many system libraries as we
can (and only resort to other sources in certain cases), hasn't
changed, of course.
Also stop having to set USE_AUTOBUILD_3P to OFF.
Lines are reindented, and when a system library can be found for
a dependency, then that should be the way. If later we find out
that using some other way is better, than stick to that. So, one
option at a time, whichever is best for the situation.
GLEXT hasn't been used, and in order to be not having to hack its
.cmake file, we bypass it and refer to GLH (which is still used)
right away in LLWindow.
CMake commands that need to be bypassed, if it's a one-liner then
it's just commented out, but if it's multiple lines, then scope
them with if (FALSE) to minimise difference.
|
|
On macOS, it's static library too, now, hence the stream editing is
done out of any platform scope (which it's still needed because
BUILD_SHARED_LIBS is ignored), and the (so)versions don't need to be
set any more.
CMAKE_INSTALL_LIBDIR is also ignored, hence the libcollada14dom.a
moving.
|
|
Turns out it wasn't forwarded, when I was building on macOS 15 arm64.
|
|
and therefore LL's Collada DOM can be upgraded to something newer
than r4, and therefore PCRE can be no longer depended on.
Have to set the C++ standard so it doesn't use anything old, but
also it wasn't ready for something as new as C++20 yet, that's why
it's explicitly set to C++17.
Have to set the architecture too when you're cross-compiling,
it would use the native architecture.
|
|
|
|
Also simplify CMake-based dependency projects, the parameters that
have been set for the viewer seem to have been implied all this time
for the subprojects.
|
|
I thought /opt/local/include wasn't needed since we switched to boost181,
but PCRE headers are there. If you still have "boost" installed (maybe
depended on by some other package, just deactivate it first before cmake).
|
|
so we don't need the boost package or the -no_static variant of
boost181 any more.
|
|
|
|
2024.08-DeltaFPS
|
|
|
|
repository.
|
|
Clone the repository by git and make it a cmake submodule.
|
|
|
|
by managing to compile LL's ColladaDOM 2.3 on-the-fly.
|
|
Spaces are really just troublesome in argument passing. They can't
really be escaped, quoting from -D would even replace spaces with
semicolons. Hence making use of every variable that can be used in
Collada DOM's CMakeLists.txt.
|
|
This reverts commit 3bba39cf3e4d56da5aba883479539ed89fa578b9.
|
|
|
|
So that colladadom_installed won't throw USESYSTEMLIBS to the next
scope.
Also libpcrecpp_LIBRARIES doesn't take spaces (might work by escaping
the quotes, but only 1 pcrecpp needed anyway).
|
|
Turns out getting 2.3 compiled on those platforms need a lot more
attention.
Apart from that, the compilation result variable name got fixed,
the prebuilt include directory got fixed, and pkg-config-ing minizip,
libpcrecpp and libxml-2.0 so we can make have generic variable arguments
to pass to Collada DOM's CMake settings.
|
|
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.
|
|
packages (#2250)
Rebuild expat, apr, meshoptimizer, ogg_vorbis, libjpeg-turbo for symbol fixes
|
|
|
|
source for viewer 7.1.7.8974243247
|
|
LF, and trim trailing whitespaces as needed
|
|
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.
|
|
|
|
allow us to reuse the macro for more than just conan.
|
|
on Linux again.
|
|
|
|
All 3Ps include dirs are treated as SYSTEM, this will stop compilers
stop emitting warnings from those files and greatly helps having high
warning levels and not being swamped by warnings that come from
external libraries.
|
|
enough now).
|
|
with the same name (that's why 3ps had names like apr::apr),
but it's safer and saner to put the LL 3ps under the ll:: prefix.
This also allows means it is possible to get rid of that bad "if( TRAGET ...) return() endif()" pattern and rather use include_guard().
|
|
Change projects to cmake targetsto get rid of havig to hardcore
include directories and link libraries in consumer projects.
|
|
|
|
|
|
|
|
Updating SDL to 290561, c-ares to 290399, Boost to 290566, colladadom
to 290576, curl to 290567, fontconfig to 290569, freetype to 290557,
google-mock to 290574, libpng to 290558, libxml2 to 290562, llqtwebkit
to 290578, openssl to 290560, PCRE to 290406, zlib to 290556. Document
compiling and linking in new 00-COMPILE-LINK-RUN.txt in indra/cmake. It
is the README for the building process based on things learned during
this library project. Switch building process back to style used for
new llqtwebkit2 repo. This builds shared libraries for Qt4 products
on all platforms using current build machines and TC task templates.
All platforms are building. All have comparable FPS rates. Builds are
getting quieter. Forward, comrades!
|
|
Release and Debug builds working. Remove the DOM_DYNAMIC define so
that we don't create declspec declarations to colladadom objects
and pull in libxml2_a (_a for archive) to complete the link. Debug
functional and would be moreso if not for all the CrtCheckMemory()
calls.
|
|
colladadom to 290229, curl to 290186, fontconfig to 290258, freetype to 290255,
google-mock/gmock/gtest to 290199, libpng to 290081, libxml2 to 290157,
llqtwebkit to 290262/250147 (to be fixed shortly), openssl to 290083,
pcre to 290150, zlib to 290080. The freetype2 headers are now normalized
to what they would normally be on a unix-type system. Libxml2 and
pcre are available on all platforms. Libraries generally move in the
direction of static archives rather than shared libraries (e.g. openssl).
The llqtwebkit side is a step back from the more ambitious goal. What
will be used (290262) will be a simple rebuild of the existing 4.7.1
library with updated package dependencies. The bigger work will be in
the future.
|
