| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit 32871ee579bfbd4828f7888550897f619fdfd9d7.
|
|
|
|
|
|
This reverts commit 75012c4f0c0b852c8bfa0b5632bf82c82f240754.
I realised I was in the wrong direction after I avoided the
offending lines by setting GLM_FORCE_XYZW_ONLY, and then by setting
GLM_FORCE_CXX_UNKNOWN, to end up with the same 16 __m128-related
"too many initializers" errors, which I believe were just obscured
by the 160 syntax errors, which are to be fixed in the next commit.
I had already mentioned SSE2NEON being responsible for translating
__m128, but I had forgotten that it was a different package from
GLM, obviously, that __m128 was never GLM_FORCE_NEON's
responsibility.
|
|
though there are still so many compile errors, but it should be in
the right direction, cause firstly we can't let it use GLM_FORCE_SSE2
otherwise it would include x/emmintrin headers, and secondly, if
none of the GLM_FORCEs is used then the errors are much fewer but
related to __m128 which should be translatable by SSE2NEON (that's
why I believe GLM_FORCE_NEON should be ON for Windows arm64 too).
|
|
This commit is for getting rid of the compile error for now,
we don't know yet if this will work correctly or not.
|
|
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.
|
|
|
|
It's irrelevant on any distro anyway.
|
|
Parsing failed on macOS' CMake (could be MacPorts, could be the version)
for some reason.
|
|
cURL is installed on arm64 cause there doesn't seem to be any easy
way to build OpenSSL 1.1 for Windows arm64 (which LL's cURL fork
depends on).
|
|
Crow Misia's libwebrtc-bin, the one we've been relying on for WebRTC
binaries, doesn't seem to be providing Windows arm64 binaries yet.
|
|
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.
|
|
|
