| Age | Commit message (Collapse) | Author |
|---|
|
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]
|
|
Put the necessary files into place.
But, none of them is working just yet.
|
|
and make the if, else, & endif styles more consistent.
|
|
Adding another library file to link means adding many more lines
for other platform(s), at least for macOS with its bundling.
It's much simpler to make the condition on 2 files.
|
|
|
|
The error was "definition of dllimport static data member not allowed",
and not "definition of dllimport function not allowed" as mentioned in
commit 2bf9d234aac30ed4a85282730da0ffc83acf9adf description.
Basically there were about 5 offending files, and all had
BOOST_JSON_REQUIRE_CONST_INIT in them.
Not including json/src.hpp (that includes them among others), fixes
those errors, but then there are definitions in them that are actually
used by llsdjson.
After doing so many searches, I came across this:
https://stackoverflow.com/questions/3491990/c-definition-of-dllimport-static-data-member
and just from the first paragraph in the accepted answer, I realised
llsdjson can still have those definitions, just not from the offending
headers, but by simply linking to Boost JSON compiled library instead.
|
|
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).
|
|
This reverts commit 2bf9d234aac30ed4a85282730da0ffc83acf9adf.
|
|
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 got "definition of dllimport function not allowed" errors when using
vcpkg's Boost.
Someone else got this problem too:
https://github.com/boostorg/serialization/issues/278
Hopefully later we can get back to using vcpkg's Boost.
|
|
There doesn't seem to be glext.h on Windows, so we'll just use the
package from LL for now.
|
|
|
|
|
|
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.
|
|
|
|
This reverts commit 3a36cdf6ebd9d2795bdcd14162f38df568d51796.
|
|
On some platforms where there's no such system library, and no
prebuilt binaries for them, Expat needs to be built first before
APR, because apr-util depends on Expat.
|
|
on the CMake string match tests.
|
|
to make it more flexible the next time a value in the if's parentheses
gets changed again, and also to reduce duplicate pattern matches when
grepping those CMake files with certain keywords.
|
|
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.
|
|
|
|
|
|
GCC needs cstdint header inclusion for it to compile.
include/cef needs to exist first otherwise configuration would fail.
INSTALL_RPATH is needed in try_compile-ing.
PROJECT_ARCH needs to be set on aarch64 to avoid -m64 and
-march(=x86-64) settings which aren't recognised (and wouldn't be
correct) on aarch64.
ENABLE_CXX11_ABI needs to be set ON, otherwise it would use C++ 03's ABI
and cause a linking failure.
Dullahan headers don't seem to be included in the installation upstream,
and dullahan_version.h gets generated only at least after Dullahan
configuration, hence the 2 files copying.
dullahan_host rpath removal is taken out of scope because the Fedora we
support isn't only x86-64 now.
The reindentations are just to make the uniform with the rest in the
file.
|
|
|
|
|
|
Shorter.
|
|
Simpler.
|
|
Same as reason as previous commit, plus the moving of OpenSSL libs
up 1 directory is still needed.
|
|
so there's no need to have the long list of installed files.
openssldir is set to isolate the files so they won't pollute
the packages directory (which could lead to confusion).
|
|
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.
|
|
Same as previous commits, plus reminding CMAKE_BUILD_WITH_INSTALL_RPATH
needs to be set ON otherwise there would be configure error on FreeBSD,
plus the codec executables aren't needed (they would encounter linking
errors on FreeBSD, because /usr/local/lib isn't automatically added as
a header search directory).
By default OpenJPEG installation header directory is "openjpeg-2.5",
hence the renaming.
The 3 non-API headers are copied, still.
|
|
and use ARCH_PREBUILT_DIRS_RELEASE for shortening paths.
|
|
CMAKE_OSX_ARCHITECTURES & CMAKE_OSX_DEPLOYMENT_TARGET won't affect non-macOS.
Settings such as those 2, and CMAKE_BUILD_TYPE, aren't inherited,
so the significant ones should be set explicitly.
Meshoptimizer default installation header directory is without the
encapsulating "meshoptimizer" directory.
|
|
|
|
so that the C90 standard setting is not used when compiling other
dependencies such as OpenJPEG.
|
|
getpwuid_r, which is declared in /usr/include/pwd.h, somehow is always
missed by, at least the custom, libcurl compiling process. I tried
defining __USE_POSIX so the getpwuid_r part in pwd.h is included, I also
tried undefining HAVE_GETPWUID_R so the getpwuid_r part in curl/lib/netrc.c
is skipped (respectively using -D and -U CPPFLAGS ENV setting in
indra/cmake/CURL.cmake), with no success.
So just force the getpwuid_r part in netrc.c to be skipped by
substituting defined(HAVE_GETPWUID_R) with 0.
|
|
|
|
Media plugins enabling not yet.
OpenXR is disabled for now (it hasn't been used anyway).
perl-FindBin is needed to be able to build OpenSSL on Fedora aarch64.
Setting the C standard to 90 when building cURL is needed, otherwise
it would fail at configure time with a misleading error of not finding
link/run time requirements for dependencies (such as nghttp2 and zlib),
at least on Fedora (and macOS too back then, I remember).
GCC treated SSE2NEON warnings as errors on so many files,
so -Wno-cpp is added globally.
The same Linux CPU frequency calculation needs to be out of the x86 scope,
otherwise the viewer would complain about not meeting the requirements
at launch time.
|
|
Turns out it wasn't forwarded, when I was building on macOS 15 arm64.
|
|
|
|
|
|
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.
|
|
Since the last merge, the prebuilt version has been used for all
Megapahit platforms, when some should've used the system version instead,
as instructed.
And then, not all Linux distros don't have sufficient version of GLM on
their repos, some do have and have already been instructed to install
system GLM anyway.
So the distros that still have insufficient version of GLM (0.9.9.8
instead of the necessary 1.0.1) are Debian, Ubuntu and openSUSE
Tumbleweed, while other distros and OSes have GLM 1.0.1.
|
|
|
|
|
|
reduce build time
|
|
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.
|
|
|
|
|
