Unable to build under Windows

[Maghoumi]

Unfortunately, I am unable to build the library under Windows 10 using Visual Studio 2013 (for x64). CMake runs fine: I manually specified the path to eigen and I have manually compiled pugixml and have specified its library file and include directory. I've never used meta and I have no idea what it does. But I suspect meta is the culprit here. I can see that sine meta is not detected on my machine, the build script would use git to clone the latest version and then halts!

Here's what VS2013 output gives me:

1>------ Build started: Project: ZERO_CHECK, Configuration: Debug x64 ------
2>------ Build started: Project: ApproxMVBB_PredInitGenInternal, Configuration: Debug x64 ------
3>------ Build started: Project: meta, Configuration: Debug x64 ------
2>cl : Command line warning D9002: ignoring unknown option '/EH;'
2>cl : Command line warning D9002: ignoring unknown option '/EH/'
2>cl : Command line warning D9002: ignoring unknown option '/EHM'
2>cl : Command line warning D9002: ignoring unknown option '/EHP'
2>  PredicatesInit.cpp
2>C:\Users\magho_000\Desktop\ApproxMVBB\external\GeometryPredicates\src\PredicatesInit.cpp(70): warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
2>          C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\stdio.h(211) : see declaration of 'fopen'
3>  Creating directories for 'meta'
3>  Performing download step (git clone) for 'meta'
3>  Cloning into 'meta'...
3>  Already on 'master'
3>  Your branch is up-to-date with 'origin/master'.
3>  Submodule 'doc/gh-pages' (https://github.com/ericniebler/meta.git) registered for path 'doc/gh-pages'
3>  Cloning into 'doc/gh-pages'...
3>  Submodule path 'doc/gh-pages': checked out '23d49cfb19b58a13089fb12e6ac65465e254eeb2'
3>  Performing update step for 'meta'
3>  Current branch master is up to date.
3>  No patch step for 'meta'
3>  Performing configure step for 'meta'
3>  -- The CXX compiler identification is MSVC 18.0.21005.1
3>  -- Check for working CXX compiler using: Visual Studio 12 2013 Win64
3>  -- Check for working CXX compiler using: Visual Studio 12 2013 Win64 -- works
3>  -- Detecting CXX compiler ABI info
3>  -- Detecting CXX compiler ABI info - done
3>  -- Detecting CXX compile features
3>  -- Detecting CXX compile features - done
3>  CMake Warning (dev) at CMakeLists.txt:16 (if):
3>    Policy CMP0054 is not set: Only interpret if() arguments as variables or
3>    keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
3>    details.  Use the cmake_policy command to set the policy and suppress this
3>    warning.
3>  
3>    Quoted variables like "MSVC" will no longer be dereferenced when the policy
3>    is set to NEW.  Since the policy is not set the OLD behavior will be used.
3>  This warning is for project developers.  Use -Wno-dev to suppress it.
3>  
3>  -- Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE) 
3>  -- Found Git: C:/Program Files (x86)/Git/cmd/git.exe (found version "1.9.5.msysgit.1") 
3>  -- Doxygen not found; the 'doc' and 'gh-pages.{clean,copy,update}' targets will be unavailable.
3>  -- Configuring done
3>  -- Generating done
3>  -- Build files have been written to: C:/Users/magho_000/Desktop/Build/src/meta-build
3>  No build step for 'meta'
3>  No install step for 'meta'
3>  Completed 'meta'

At this point, the build process halts (as if trapped in a deadlock) and there's nothing I can do other than force close MSBuild process. Any help is greatly appreciated :)

[gabyx]

can you update to the latest version of cmake? I think it is a stupid cmake problem... Meta is a meta programming library and you can simply download it and specify the include directory where it belongs :-). In your case, meta has been setup up as en external project which downloads the header files from github and uses them. it seems not to work with your Cmake , either because of windows or cmake...

However, specify the include folder directly when configuring the first time To do this: run cmake from command line:

cmake pathToApproxRepo  -DMeta_INCLUDE_DIR="/path/meta/"

That should hopefully work

[gabyx]

Shit I closed, this Please keep me updated

[Maghoumi]

Thanks for the reply. The machine I was using did not have CMake and I had to download and install it. I'm pretty sure I was using the latest version. I will get back to you soon with the results. Thanks again.

[Maghoumi]

OK so I tried things again (on another machine). It seems that I had changed a few things in the files checked out from the repo. I cloned the repo again and now there seems to be a few issues.

In CMake, I manually defined the Meta flag you specified and during configuration a few tests fail:

I can hit ignore and the configuration process continues (a couple of other tests fail as well). After that, I get this error which I'm assuming has something to do with the install directions:

I can mute these errors by commenting out the INSTALL lines in the corresponding CMake file (beginning at line 72).

CMake then gives me the VS2013 solution files. Upon attempting to build them, I get loads of compile errors:

I am clueless :(

I found ApproxMVBB from StackOverflow (this question: http://stackoverflow.com/questions/6189229/creating-oobb-from-points). I'm having issues with Gottschalk's algorithm. I get wrong boxes when the input data is symmetric (eg. cubes as described in the original post). That's why I need to give ApproxMVBB a try to see if solves my problems. Any help is greatly appreciated.

[gabyx]

First of all, the library solves your problem for sure. The problem is your toolchain and the lacking support for windows of this library I think.

I see, 2 problems, here, first the library has not been tested for windows, you are the first one :) the debug assertion which occures (is due to cmake right?) and is that the CPP file which is compiled and checked in cmake/CheckFloatPrecision.cmake is crashing, hm... thats not good. This script is not from me and only checks if some special FLOATING point control is available, sadly... I dont know if that is bad, because it seems it found HAVE_CONTROL_FP and _S ...

I would strongly suggest using a newer and better compiler (the compile errors you get is because I did not add --std=c++11 to the CMAKE_CXX_FLAGS for MVCC (try to add it there). Could you install GCC on windows with MINGW http://www.mingw.org/. And try to use the GCC compiler, this is much better because MVCC13 is not so compliant with the standart I guess... but try it ou :)

[gabyx]

or maybe install clang :-)

[Maghoumi]

Unfortunately, using MinGW is not an option for me. I plan on using ApproxMVBB in C# (via a wrapper) and as far as I know, using MinGW compiled binaries that way is very difficult (if not impossible). I will try out the c++11 flag (didn't notice it was missing) and see what happens.

[Maghoumi]

Apparently VC++ has C++11 enabled by default (no flag necessary!) (per http://stackoverflow.com/questions/24462371/enable-c11-support-in-vs-2013-from-cmake)

Also, what was that Cmake error message: install library TARGETS given no DESTINATION?

Also, I'm seeing another entry in Cmake: Meta_TARGET. It is a path entry... What is that? I tried assigning an actual path to it but it reverts back to being blank if I hit the Configure button again.

Thanks :)

[gabyx]

did you try to configure over the command line by giving

cmake pathToApproxRepo  -DMeta_INCLUDE_DIR="/path/meta/"

If you set the path directly at the first configuration (delete CMakeCache.txt first!) it will be used, and Meta is not downloaded from Github!

Hm... shitty MSVC, gcc and clang compile without any problem, I think you only wanna compile ApproxMVBB into a library right and then use this library in C#. Is a GCC (mingw) compiled library not usable under windows? (meaning, .lib, .dll?)

[Maghoumi]

Gabriel, Regarding

did you try to configure over the command line by giving

Yes! I'm invoking cmake with cmake ../ApproxMVBB -DMeta_INCLUDE_DIR="../" (have the meta include files in "../" (one directory above build)).

Is a GCC (mingw) compiled library not usable under windows? (meaning, .lib, .dll?)

There are a few issues if I build with Cygwin and then try to create C# wrapper around it. Most importantly, whoever wants to compile and use my code would have to install and configure Cygwin. As you already know, code compiled using Cygwin would require Cygwin's runtime libraries to run and the users of my code would need to install and configure Cygwin environment. This is currently not feasible since the project is mostly written in C# (with some minor dependencies to CGAL). Currently, any novice C# programmer would be able to compile and run my project without having to deal with all the C/C++ and wrappers crap.

However, I went ahead and gave Cygwin a try. After some painful hours, I was able to compile the library and run only one of the examples (will explain more below).

A few things: 1) One of the external tools you've used has problems with Cygwin. I'm referring to Diameter under external directory. In rand.cpp, there are a few #ifdef WIN32 guards. These guard only works with MSVC. Cygwin preprocessor has different defines for Windows. I think you should use #if defined _WIN32 || defined __CYGWIN__ instead.

2) (This one is a bit difficult to explain for me) There seems to be a problem that causes Platform.hpp to fail with respect to defining __declspec(dllexport) and __declspec(dllimport). I would assume that because I am building DLL files, I would have to have __declspec(dllexport) defined. Yet for some reason unknown to me, dllimport was defined and I was getting compile errors. I manually changed that file to have only __declspec(dllexport) and that solved the issues. Perhaps the cmake files do not correctly define the conditions that lead to the incorrect definition of dllimport. My knowledge is limited and you are the C expert :)

3) I could not build the kdtree example. It was complaining about not being able to find meta.hpp. Although (as indicated above) I had added the flag regarding the location of meta, I was still getting errors. Again, I'm not expert in C or cmake, but line 22 of CMakeLists.txt in kdTreeFiltering indicates ApproxMVBB_INC_DIRS as a dependency, however line 123 of CMakeLists in ApproxMVBB folder says SET(ApproxMVBB_INC_DIRS_DEP ${EIGEN_INCLUDE_DIR} ${PUGIXML_INCLUDE_DIR} ${Meta_INCLUDE_DIR}): there is a _DEP at the end. I don't know if that's what causing meta not to be found.

After seeing the results of example with the unit cube, I would really like to give ApproxMVBB a try under MSVC so that I can see how it does with the rest of my C# stuff. If you can think of anything that I can try to get it to work with MSVC, please let me know. Thanks :)

[gabyx]

Thanks for the reply, I would like to help, unfortunately I am extremely busy right, now. It is a pitty that it is so complicated with cygwin and windows.

unfortunately I dont have a windows workstation here to test it

I added the windows stuff to hopefully make it work on windows but never actually tested it :-) the code when it compiles should hopefully work, if the FPU_CONTROL stuff is properly configured (Geometric Predicates needs fpu control stuff, and the Target "PredInit" executes a CPP file which generates Hardware dependent initialization numbers for the Geometric Predicate code. So I have to rethink again about the initialization, when you wanna distribute your c# code or rather the code which uses ApproxMVBB, you need to be aware that these initialization values are HARDWARE dependent, and I think I can make an initialization function (there is one, need to relocate it) which can be called before any call to ApproxMVBB is issued.

ok: Platform.cpp is defintely something fishy, you are right, ApproxMVBB_BUILD_LIBRARY is not defined in the configured Config.hpp I will correct this!

I also fix the config.hpp, look for a pull in 3-4 hours! then you can try again, if the stupid platform.hpp works :-) Would be cool to make it work under windows.

I can understand about cygwin, its not easy at all, but first lets make it work under cygwin, then start maybe from scratch and try to build it under windows MSVC.. lets see :)

[gabyx]

Try to checkout the latest master branch, (redo it if you have already, because I amended something :-))

I corrected the Platformstuff hopefully it will work, let me know, if it doesnt and you can fix it, please feel free to provide a pull request :-)! and the Macros _WIN32 stuff

[gabyx]

For the third issue: CMAKE_MAKE_VERBOSE = True and check if the include path is set during compilation of kdTreeFiltering (ApproxMVBB_INC_DIRS is correctly set in the main project , lin 171)

[Maghoumi]

Gabriel, I know how crazy stuff can get. I'm busy as well. Especially because I have an algorithm that depends on the correct computation of OBB's and have a meeting on Friday that revolves around that algorithm. That's why I'd like to get ApproxMVBB to work. So I do appreciate your help and attention :)

I pulled the most recent version and tried it out. There are still a few issues but resolving them shouldn't be that difficult. In a couple of minutes I will submit a pull request for your review. The changes create a workaround for a bug in older GCC versions. For some reason, the GCC bundled with the latest Cygwin still has that bug.

Other issues that I'm dealing with are coming from CMakeLists.txt under lib (the one you just revised). For some reason, target_compile_definitions(ApproxMVBB PRIVATE -DApproxMVBB_BUILD_LIBRARY) is still not working. When compiling, Platform.hpp is still doing the dllimport thing instead of dllexport. I will try to figure out what the problem is, however my limited knowledge of CMake makes things very difficult. Another problem (that I forgot to mention before) is with install(...) directives in lib/CMakeLists.txt (starting from line 73). For CMake in Cygwin to work, I have to comment out all these install directives or I will get the error:

CMake Error at lib/CMakeLists.txt:73 (install): install Library TARGETS given no DESTINATION!

Again, with limited CMake knowledge, I don't know how to fix that. Aside from these, everything builds easily. I was able to run all 54 tests. The example works fine, however the KdTree example gives a segmentation fault without additional explanation.

[Maghoumi]

OK I tried MSVC again (just for fun). The core ApproxMVBB project won't compile due to many complaints about the macro ApproxMVBB_DEFINE_MATRIX_TYPES in various files. For some reason, that macro seems to be undefined. I suspect the CMake files do define that macro properly for MSVC (flag related maybe...?)

[gabyx]

always give absolut paths for include dirs to cmake. that should solve the meta issue.

good that it compiles. however the target_compile_definitions tries to add a pr

[gabyx]

tries to add a preprocessor define to the target such that when compiling the switch is enabled in the PlatformConfig.hpp file. so far that fails. i will check tomorrow. the kdtree segfault is nooot good. i am keen on solving all these bugs. so far the library was used in my framework wothotu troubles maxbe some stupid error is in the example... thx for the pull request i wil look at it tomorrow

[gabyx]

the matrix macro ApproxMVBB_DEFINE_MATRIX_TYPES is not defined in cmake. it is defined in the files in the config folder in includes. dont have acces to the files right now

[Maghoumi]

Take a look at this! Do you know what it means? :D

YESSS! I finally managed to build it using MSVC and run the unit cube example! THAT'S RIGHT! :dancers: But let's keep all the excitement in check. I had to hack a bunch of stuff to get it to work. A few things:

1) Ignore my comment about ApproxMVBB_DEFINE_MATRIX_TYPES not being defined The compiler was complaining about the typename keyword in different files (refer to the screenshot attached in this comment). Apparently, you were using typename without an actual template or something in a bunch of places (eg. line 30 of PointFunctions.hpp). For some reason, MVCC does not like typename keyword when there are no templates present (maybe a C++11 thing?! I dunno). What I ended up doing was to get rid of typename in all those files and functions.

2) The dllimport and dllexports were again wrongly assigned in Platform.hpp (had to manually force them to become dllexport.)

3) I was unable to build KdTree example and the tests. Too many vague errors. I just deleted the projects from the solution files.

4) In line 17 of EstimateDiameter.cpp under external/..., I had to add the APPROXMVBB_EXPORT macro: MSVC is very anal about the header and cpp file having the same function signatures. So I have this now on line 17 of that file: APPROXMVBB_EXPORT double estimateDiameter( typeSegment *theDiam,...

5) The compiler was complaining about Vector3 being ambiguous in lines 260 and 262. Had to manually change Vector3 in those lines to ApproxMVBB::MyMatrix::Vector3<ApproxMVBB::TypeDefsPoints::PREC>.

6) Only the library built in release configuration works. The debug build would fail with lots of assertion fails (similar to what I mentioned earlier with CMake configuring the project). Here's a screenshot:

Since the assertions fail, I don't even know if the results are reliable. So I probably won't use the DLL file just yet. Impatiently awaiting morning in Switzerland :-p

[gabyx]

Shit I wrote an answer, and closed the windows: ok here again:

1) Could you provide me what you replaced or deleted, (pull request if possible) I dont see any mistake so fare when comparing the pictures you send me... :-) 2) Still trying to fix this: Post the compiler output (CMAKE_MAKE_VERBOSE) of MSVC , there should be somewhere a preprocessor variable be defined as /DApproxMVBB_BUILD_LIBRARY if you can see such variables then cmake messed up...

4) fixeed that thanks

5) which file?

6) Strange, it would be very good if you could locate the point where the example crashes, (its due to floating point control stuff I think), it would help in localizing the problem... ( i think its a false positive) Because as it seems your machine is using this https://msdn.microsoft.com/en-us/library/c9676k6h.aspx

[gabyx]

Try to compile the following

#include <stdio.h>
  #include <string.h>
  #include <float.h>

  double div (double a, double b) {
    unsigned int fpu_oldcw, fpu_cw;
    volatile double result;

    _controlfp_s(&fpu_cw, 0, 0);
    fpu_oldcw = fpu_cw;
    _controlfp_s(&fpu_cw, _PC_53, _MCW_PC);
    result = a / b;
    _controlfp_s(&fpu_cw, fpu_oldcw, _MCW_PC);
    return result;
  }

  int main (int argc, char **argv) {
    double d = div (2877.0, 1000000.0);
    char buf[255];
    sprintf(buf, \"%.30f\", d);
    // see if the result is actually in double precision
    return strncmp(buf, \"0.00287699\", 10) == 0 ? 0 : 1;
  }

and replace one the _PC_53 with _PC_64. It might be that _PC_53 raises an exception because it is not notsupported, and THAT is actually a problem, we need to make the CPU Floating Point Engine (double precision NOT Extendet Precision which is _PC_64)

[gabyx]

Lets see if there is a possibilty

[gabyx]

[gabyx]

If there will be problems with certain tests (which means they fail to produce the correct box, we could try to use the flag "/fp:precise" for MSVC maybe that helps:

The underlying problem is the following https://www.cs.cmu.edu/~quake/robust.pc.html

[gabyx]

For further information: also for me here a good link : https://software.intel.com/sites/default/files/article/164389/fp-consistency-102511.pdf

[Maghoumi]

1) Could you provide me what you replaced or deleted, (pull request if possible) I dont see any mistake so fare when comparing the pictures you send me... :-)

Sure. I will do that some time later today.

2) Still trying to fix this: Post the compiler output (CMAKE_MAKE_VERBOSE) of MSVC , there should be somewhere a preprocessor variable be defined as /DApproxMVBB_BUILD_LIBRARY if you can see such variables then cmake messed up...

Shit! Sorry I forgot to post the VERBOSE output. Here is goes:

$ make VERBOSE=1
/usr/bin/cmake.exe -H/home/Mehran/ApproxMVBB -B/home/Mehran/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake.exe -E cmake_progress_start /home/Mehran/build/CMakeFiles /home/Mehran/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory '/home/Mehran/build'
make -f CMakeFiles/ApproxMVBB-Release_PredInitGenInternal.dir/build.make CMakeFiles/ApproxMVBB-Release_PredInitGenInternal.dir/depend
make[2]: Entering directory '/home/Mehran/build'
cd /home/Mehran/build && /usr/bin/cmake.exe -E cmake_depends "Unix Makefiles" /home/Mehran/ApproxMVBB /home/Mehran/ApproxMVBB /home/Mehran/build /home/Mehran/build /home/Mehran/build/CMakeFiles/ApproxMVBB-Release_PredInitGenInternal.dir/DependInfo.cmake --color=
make[2]: Leaving directory '/home/Mehran/build'
make -f CMakeFiles/ApproxMVBB-Release_PredInitGenInternal.dir/build.make CMakeFiles/ApproxMVBB-Release_PredInitGenInternal.dir/build
make[2]: Entering directory '/home/Mehran/build'
[  3%] Building CXX object CMakeFiles/ApproxMVBB-Release_PredInitGenInternal.dir/external/GeometryPredicates/src/PredicatesInit.cpp.o
/usr/bin/c++.exe    -std=c++11 -fmax-errors=50 -Werror=return-type  -O3 -DNDEBUG -I/home/Mehran/ApproxMVBB/external/GeometryPredicates/include -I/home/Mehran/build/include    -o CMakeFiles/ApproxMVBB-Release_PredInitGenInternal.dir/external/GeometryPredicates/src/PredicatesInit.cpp.o -c /home/Mehran/ApproxMVBB/external/GeometryPredicates/src/PredicatesInit.cpp
[  6%] Linking CXX executable ApproxMVBB-Release_PredInitGenInternal.exe
/usr/bin/cmake.exe -E cmake_link_script CMakeFiles/ApproxMVBB-Release_PredInitGenInternal.dir/link.txt --verbose=1
/usr/bin/c++.exe  -std=c++11 -fmax-errors=50 -Werror=return-type  -O3 -DNDEBUG  -Wl,--enable-auto-import CMakeFiles/ApproxMVBB-Release_PredInitGenInternal.dir/external/GeometryPredicates/src/PredicatesInit.cpp.o  -o ApproxMVBB-Release_PredInitGenInternal.exe -Wl,--out-implib,libApproxMVBB-Release_PredInitGenInternal.dll.a -Wl,--major-image-version,0,--minor-image-version,0
make[2]: Leaving directory '/home/Mehran/build'
[  6%] Built target ApproxMVBB-Release_PredInitGenInternal
make -f CMakeFiles/ApproxMVBB-Release_PredInitGen.dir/build.make CMakeFiles/ApproxMVBB-Release_PredInitGen.dir/depend
make[2]: Entering directory '/home/Mehran/build'
cd /home/Mehran/build && /usr/bin/cmake.exe -E cmake_depends "Unix Makefiles" /home/Mehran/ApproxMVBB /home/Mehran/ApproxMVBB /home/Mehran/build /home/Mehran/build /home/Mehran/build/CMakeFiles/ApproxMVBB-Release_PredInitGen.dir/DependInfo.cmake --color=
make[2]: Leaving directory '/home/Mehran/build'
make -f CMakeFiles/ApproxMVBB-Release_PredInitGen.dir/build.make CMakeFiles/ApproxMVBB-Release_PredInitGen.dir/build
make[2]: Entering directory '/home/Mehran/build'
[  9%] Generating include/ApproxMVBB/GeometryPredicates/PredicatesInit.hpp
cd /home/Mehran/build/include/ApproxMVBB/GeometryPredicates && /home/Mehran/build/ApproxMVBB-Release_PredInitGenInternal.exe
make[2]: Leaving directory '/home/Mehran/build'
[  9%] Built target ApproxMVBB-Release_PredInitGen
make -f lib/CMakeFiles/ApproxMVBB.dir/build.make lib/CMakeFiles/ApproxMVBB.dir/depend
make[2]: Entering directory '/home/Mehran/build'
cd /home/Mehran/build && /usr/bin/cmake.exe -E cmake_depends "Unix Makefiles" /home/Mehran/ApproxMVBB /home/Mehran/ApproxMVBB/lib /home/Mehran/build /home/Mehran/build/lib /home/Mehran/build/lib/CMakeFiles/ApproxMVBB.dir/DependInfo.cmake --color=
Dependee "include/ApproxMVBB/GeometryPredicates/PredicatesInit.hpp" is newer than depends file "/home/Mehran/build/lib/CMakeFiles/ApproxMVBB.dir/depend.internal".
Clearing dependencies in "/home/Mehran/build/lib/CMakeFiles/ApproxMVBB.dir/depend.make".
Scanning dependencies of target ApproxMVBB
make[2]: Leaving directory '/home/Mehran/build'
make -f lib/CMakeFiles/ApproxMVBB.dir/build.make lib/CMakeFiles/ApproxMVBB.dir/build
make[2]: Entering directory '/home/Mehran/build'
[ 12%] Building CXX object lib/CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/Common/MyMatrixTypeDefs.cpp.o
cd /home/Mehran/build/lib && /usr/bin/c++.exe   -DApproxMVBB_BUILD_LIBRARY -DApproxMVBB_EXPORTS -std=c++11 -fmax-errors=50 -Werror=return-type  -fvisibility=hidden  -DApproxMVBB_BUILD_LIBRARY -O3 -DNDEBUG -I/home/Mehran/ApproxMVBB/external/GeometryPredicates/include -I/home/Mehran/build/include -I/usr/include/eigen3 -I/home/Mehran/ApproxMVBB/external/Diameter/include -I/home/Mehran/ApproxMVBB/include -I/home/Mehran/build/src/meta/include    -o CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/Common/MyMatrixTypeDefs.cpp.o -c /home/Mehran/ApproxMVBB/src/ApproxMVBB/Common/MyMatrixTypeDefs.cpp
[ 16%] Building CXX object lib/CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/ConvexHull2D.cpp.o
cd /home/Mehran/build/lib && /usr/bin/c++.exe   -DApproxMVBB_BUILD_LIBRARY -DApproxMVBB_EXPORTS -std=c++11 -fmax-errors=50 -Werror=return-type  -fvisibility=hidden  -DApproxMVBB_BUILD_LIBRARY -O3 -DNDEBUG -I/home/Mehran/ApproxMVBB/external/GeometryPredicates/include -I/home/Mehran/build/include -I/usr/include/eigen3 -I/home/Mehran/ApproxMVBB/external/Diameter/include -I/home/Mehran/ApproxMVBB/include -I/home/Mehran/build/src/meta/include    -o CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/ConvexHull2D.cpp.o -c /home/Mehran/ApproxMVBB/src/ApproxMVBB/ConvexHull2D.cpp
[ 19%] Building CXX object lib/CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/MinAreaRectangle.cpp.o
cd /home/Mehran/build/lib && /usr/bin/c++.exe   -DApproxMVBB_BUILD_LIBRARY -DApproxMVBB_EXPORTS -std=c++11 -fmax-errors=50 -Werror=return-type  -fvisibility=hidden  -DApproxMVBB_BUILD_LIBRARY -O3 -DNDEBUG -I/home/Mehran/ApproxMVBB/external/GeometryPredicates/include -I/home/Mehran/build/include -I/usr/include/eigen3 -I/home/Mehran/ApproxMVBB/external/Diameter/include -I/home/Mehran/ApproxMVBB/include -I/home/Mehran/build/src/meta/include    -o CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/MinAreaRectangle.cpp.o -c /home/Mehran/ApproxMVBB/src/ApproxMVBB/MinAreaRectangle.cpp
[ 22%] Building CXX object lib/CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/OOBB.cpp.o
cd /home/Mehran/build/lib && /usr/bin/c++.exe   -DApproxMVBB_BUILD_LIBRARY -DApproxMVBB_EXPORTS -std=c++11 -fmax-errors=50 -Werror=return-type  -fvisibility=hidden  -DApproxMVBB_BUILD_LIBRARY -O3 -DNDEBUG -I/home/Mehran/ApproxMVBB/external/GeometryPredicates/include -I/home/Mehran/build/include -I/usr/include/eigen3 -I/home/Mehran/ApproxMVBB/external/Diameter/include -I/home/Mehran/ApproxMVBB/include -I/home/Mehran/build/src/meta/include    -o CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/OOBB.cpp.o -c /home/Mehran/ApproxMVBB/src/ApproxMVBB/OOBB.cpp
[ 25%] Building CXX object lib/CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/AABB.cpp.o
cd /home/Mehran/build/lib && /usr/bin/c++.exe   -DApproxMVBB_BUILD_LIBRARY -DApproxMVBB_EXPORTS -std=c++11 -fmax-errors=50 -Werror=return-type  -fvisibility=hidden  -DApproxMVBB_BUILD_LIBRARY -O3 -DNDEBUG -I/home/Mehran/ApproxMVBB/external/GeometryPredicates/include -I/home/Mehran/build/include -I/usr/include/eigen3 -I/home/Mehran/ApproxMVBB/external/Diameter/include -I/home/Mehran/ApproxMVBB/include -I/home/Mehran/build/src/meta/include    -o CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/AABB.cpp.o -c /home/Mehran/ApproxMVBB/src/ApproxMVBB/AABB.cpp
[ 29%] Building CXX object lib/CMakeFiles/ApproxMVBB.dir/__/external/Diameter/src/EstimateDiameter.cpp.o
cd /home/Mehran/build/lib && /usr/bin/c++.exe   -DApproxMVBB_BUILD_LIBRARY -DApproxMVBB_EXPORTS -std=c++11 -fmax-errors=50 -Werror=return-type  -fvisibility=hidden  -DApproxMVBB_BUILD_LIBRARY -O3 -DNDEBUG -I/home/Mehran/ApproxMVBB/external/GeometryPredicates/include -I/home/Mehran/build/include -I/usr/include/eigen3 -I/home/Mehran/ApproxMVBB/external/Diameter/include -I/home/Mehran/ApproxMVBB/include -I/home/Mehran/build/src/meta/include    -o CMakeFiles/ApproxMVBB.dir/__/external/Diameter/src/EstimateDiameter.cpp.o -c /home/Mehran/ApproxMVBB/external/Diameter/src/EstimateDiameter.cpp
[ 32%] Building CXX object lib/CMakeFiles/ApproxMVBB.dir/__/external/Diameter/src/alloc.cpp.o
cd /home/Mehran/build/lib && /usr/bin/c++.exe   -DApproxMVBB_BUILD_LIBRARY -DApproxMVBB_EXPORTS -std=c++11 -fmax-errors=50 -Werror=return-type  -fvisibility=hidden  -DApproxMVBB_BUILD_LIBRARY -O3 -DNDEBUG -I/home/Mehran/ApproxMVBB/external/GeometryPredicates/include -I/home/Mehran/build/include -I/usr/include/eigen3 -I/home/Mehran/ApproxMVBB/external/Diameter/include -I/home/Mehran/ApproxMVBB/include -I/home/Mehran/build/src/meta/include    -o CMakeFiles/ApproxMVBB.dir/__/external/Diameter/src/alloc.cpp.o -c /home/Mehran/ApproxMVBB/external/Diameter/src/alloc.cpp
[ 35%] Building CXX object lib/CMakeFiles/ApproxMVBB.dir/__/external/Diameter/src/util.cpp.o
cd /home/Mehran/build/lib && /usr/bin/c++.exe   -DApproxMVBB_BUILD_LIBRARY -DApproxMVBB_EXPORTS -std=c++11 -fmax-errors=50 -Werror=return-type  -fvisibility=hidden  -DApproxMVBB_BUILD_LIBRARY -O3 -DNDEBUG -I/home/Mehran/ApproxMVBB/external/GeometryPredicates/include -I/home/Mehran/build/include -I/usr/include/eigen3 -I/home/Mehran/ApproxMVBB/external/Diameter/include -I/home/Mehran/ApproxMVBB/include -I/home/Mehran/build/src/meta/include    -o CMakeFiles/ApproxMVBB.dir/__/external/Diameter/src/util.cpp.o -c /home/Mehran/ApproxMVBB/external/Diameter/src/util.cpp
[ 38%] Building CXX object lib/CMakeFiles/ApproxMVBB.dir/__/external/Diameter/src/rand.cpp.o
cd /home/Mehran/build/lib && /usr/bin/c++.exe   -DApproxMVBB_BUILD_LIBRARY -DApproxMVBB_EXPORTS -std=c++11 -fmax-errors=50 -Werror=return-type  -fvisibility=hidden  -DApproxMVBB_BUILD_LIBRARY -O3 -DNDEBUG -I/home/Mehran/ApproxMVBB/external/GeometryPredicates/include -I/home/Mehran/build/include -I/usr/include/eigen3 -I/home/Mehran/ApproxMVBB/external/Diameter/include -I/home/Mehran/ApproxMVBB/include -I/home/Mehran/build/src/meta/include    -o CMakeFiles/ApproxMVBB.dir/__/external/Diameter/src/rand.cpp.o -c /home/Mehran/ApproxMVBB/external/Diameter/src/rand.cpp
[ 41%] Building CXX object lib/CMakeFiles/ApproxMVBB.dir/__/external/GeometryPredicates/src/Predicates.cpp.o
cd /home/Mehran/build/lib && /usr/bin/c++.exe   -DApproxMVBB_BUILD_LIBRARY -DApproxMVBB_EXPORTS -std=c++11 -fmax-errors=50 -Werror=return-type  -fvisibility=hidden  -DApproxMVBB_BUILD_LIBRARY -O3 -DNDEBUG -I/home/Mehran/ApproxMVBB/external/GeometryPredicates/include -I/home/Mehran/build/include -I/usr/include/eigen3 -I/home/Mehran/ApproxMVBB/external/Diameter/include -I/home/Mehran/ApproxMVBB/include -I/home/Mehran/build/src/meta/include    -o CMakeFiles/ApproxMVBB.dir/__/external/GeometryPredicates/src/Predicates.cpp.o -c /home/Mehran/ApproxMVBB/external/GeometryPredicates/src/Predicates.cpp
[ 45%] Linking CXX shared library cygApproxMVBB-1.0.10.dll
cd /home/Mehran/build/lib && /usr/bin/cmake.exe -E cmake_link_script CMakeFiles/ApproxMVBB.dir/link.txt --verbose=1
/usr/bin/c++.exe  -std=c++11 -fmax-errors=50 -Werror=return-type  -fvisibility=hidden  -DApproxMVBB_BUILD_LIBRARY -O3 -DNDEBUG   -shared -Wl,--enable-auto-import -o cygApproxMVBB-1.0.10.dll -Wl,--out-implib,libApproxMVBB.dll.a -Wl,--major-image-version,1,--minor-image-version,0 CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/Common/MyMatrixTypeDefs.cpp.o CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/ConvexHull2D.cpp.o CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/MinAreaRectangle.cpp.o CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/OOBB.cpp.o CMakeFiles/ApproxMVBB.dir/__/src/ApproxMVBB/AABB.cpp.o CMakeFiles/ApproxMVBB.dir/__/external/Diameter/src/EstimateDiameter.cpp.o CMakeFiles/ApproxMVBB.dir/__/external/Diameter/src/alloc.cpp.o CMakeFiles/ApproxMVBB.dir/__/external/Diameter/src/util.cpp.o CMakeFiles/ApproxMVBB.dir/__/external/Diameter/src/rand.cpp.o CMakeFiles/ApproxMVBB.dir/__/external/GeometryPredicates/src/Predicates.cpp.o -lpugixml
make[2]: Leaving directory '/home/Mehran/build'
[ 45%] Built target ApproxMVBB
make -f tests/CMakeFiles/ApproxMVBBTests.dir/build.make tests/CMakeFiles/ApproxMVBBTests.dir/depend
make[2]: Entering directory '/home/Mehran/build'
cd /home/Mehran/build && /usr/bin/cmake.exe -E cmake_depends "Unix Makefiles" /home/Mehran/ApproxMVBB /home/Mehran/ApproxMVBB/tests /home/Mehran/build /home/Mehran/build/tests /home/Mehran/build/tests/CMakeFiles/ApproxMVBBTests.dir/DependInfo.cmake --color=
Dependee "include/ApproxMVBB/GeometryPredicates/PredicatesInit.hpp" is newer than depends file "/home/Mehran/build/tests/CMakeFiles/ApproxMVBBTests.dir/depend.internal".
Clearing dependencies in "/home/Mehran/build/tests/CMakeFiles/ApproxMVBBTests.dir/depend.make".
Scanning dependencies of target ApproxMVBBTests
make[2]: Leaving directory '/home/Mehran/build'
make -f tests/CMakeFiles/ApproxMVBBTests.dir/build.make tests/CMakeFiles/ApproxMVBBTests.dir/build
make[2]: Entering directory '/home/Mehran/build'
[ 48%] Building CXX object tests/CMakeFiles/ApproxMVBBTests.dir/__/src/ApproxMVBB/Common/MyMatrixTypeDefs.cpp.o
cd /home/Mehran/build/tests && /usr/bin/c++.exe    -std=c++11 -fmax-errors=50 -Werror=return-type  -O3 -DNDEBUG -I/home/Mehran/ApproxMVBB/external/GeometryPredicates/include -I/home/Mehran/build/include -I/usr/include/eigen3 -I/home/Mehran/ApproxMVBB/external/Diameter/include -I/home/Mehran/ApproxMVBB/include -I/home/Mehran/build/src/meta/include -I/home/Mehran/ApproxMVBB/tests/include -I/home/Mehran/build/tests/include    -o CMakeFiles/ApproxMVBBTests.dir/__/src/ApproxMVBB/Common/MyMatrixTypeDefs.cpp.o -c /home/Mehran/ApproxMVBB/src/ApproxMVBB/Common/MyMatrixTypeDefs.cpp
/home/Mehran/ApproxMVBB/src/ApproxMVBB/Common/MyMatrixTypeDefs.cpp:15:49: warning: ‘ApproxMVBB::MyMatrixIOFormat::Matlab’ redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
         const Eigen::IOFormat MyMatrixIOFormat::Matlab = Eigen::IOFormat(Eigen::FullPrecision, 0, ", ", ";\n", "", "", "[", "]");
                                                 ^
/home/Mehran/ApproxMVBB/src/ApproxMVBB/Common/MyMatrixTypeDefs.cpp:15:31: error: definition of static data member ‘ApproxMVBB::MyMatrixIOFormat::Matlab’ of dllimport’d class
         const Eigen::IOFormat MyMatrixIOFormat::Matlab = Eigen::IOFormat(Eigen::FullPrecision, 0, ", ", ";\n", "", "", "[", "]");
                               ^
/home/Mehran/ApproxMVBB/src/ApproxMVBB/Common/MyMatrixTypeDefs.cpp:16:49: warning: ‘ApproxMVBB::MyMatrixIOFormat::CommaSep’ redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
         const Eigen::IOFormat MyMatrixIOFormat::CommaSep = Eigen::IOFormat(Eigen::FullPrecision, Eigen::DontAlignCols, ", ", "\n", "", "", "", "");
                                                 ^
/home/Mehran/ApproxMVBB/src/ApproxMVBB/Common/MyMatrixTypeDefs.cpp:17:49: warning: ‘ApproxMVBB::MyMatrixIOFormat::SpaceSep’ redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
         const Eigen::IOFormat MyMatrixIOFormat::SpaceSep = Eigen::IOFormat(Eigen::FullPrecision, Eigen::DontAlignCols, " ", "\n", "", "", "", "");
                                                 ^
tests/CMakeFiles/ApproxMVBBTests.dir/build.make:62: recipe for target 'tests/CMakeFiles/ApproxMVBBTests.dir/__/src/ApproxMVBB/Common/MyMatrixTypeDefs.cpp.o' failed
make[2]: *** [tests/CMakeFiles/ApproxMVBBTests.dir/__/src/ApproxMVBB/Common/MyMatrixTypeDefs.cpp.o] Error 1
make[2]: Leaving directory '/home/Mehran/build'
CMakeFiles/Makefile2:209: recipe for target 'tests/CMakeFiles/ApproxMVBBTests.dir/all' failed
make[1]: *** [tests/CMakeFiles/ApproxMVBBTests.dir/all] Error 2
make[1]: Leaving directory '/home/Mehran/build'
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

5) which file?

Shit! Didn't notice I didn't mention the file name :D It is in ComputeApproxMVBB.hpp

I will read/do the rest of the stuff a bit later and get back to you.

[Maghoumi]

Try to compile the following

include

include

include

double div (double a, double b) { unsigned int fpu_oldcw, fpu_cw; volatile double result;

_controlfp_s(&fpu_cw, 0, 0);
fpu_oldcw = fpu_cw;
_controlfp_s(&fpu_cw, _PC_53, _MCW_PC);
result = a / b;
_controlfp_s(&fpu_cw, fpu_oldcw, _MCW_PC);
return result;

}

int main (int argc, char **argv) { double d = div (2877.0, 1000000.0); char buf[255]; sprintf(buf, \"%.30f\", d); // see if the result is actually in double precision return strncmp(buf, \"0.00287699\", 10) == 0 ? 0 : 1; } and replace one the _PC_53 with _PC_64. It might be that _PC_53 raises an exception because it is not notsupported, and THAT is actually a > problem, we need to make the CPU Floating Point Engine (double precision NOT Extendet Precision which is _PC_64)

I tried the code with MSVC. Both _PC_64 and _PC_53 run and return 0. Honestly, I don't even know what these codes do :D BTW, I'm trying to compile the library for 64-bit system.

[gabyx]

Thanks, hm.. ok , did you run in debug mode too? ( _PC_64, sets the floating point control to extended precision, that means you are computing numbers with 64bit mantissa and 80bits - 64bits additional bits for computations, rounding and such :), we need only double precision (_PC_53) which is a normal double with 53bit mantissa which fits into 64bit (no extendet bits) (nowadays computer compute with extendet precision mostly, its better, but for our algorithm its worse, the geometric predicates of shuewshak need "no" extendet precision. If the code above does not throw an exception then everything should be fine (actually it is the same code that run when Configuring with cmake... hm...

so you still get exceptions when you run the example in debug mode?

[gabyx]

It would be helpful why debug crashes, and where it does :-) Maybe you can step through till you see where it crashes, that would be good, to be certain what the problem is maybe there are some small function call bugs in _controlfp_s which expects something else on windows, ...

[gabyx]

did you manage to make it work? :-)

[Maghoumi]

Apologizes for the delay, yesterday was Thanksgiving here and I was doing everything but work :-p

so you still get exceptions when you run the example in debug mode?

Hmm... That's weird! I noticed I was able to run it in 32-bit mode (both Debug and Release). However, when I changed it to 64-bit, I could only run it in Release mode!! Debug mode gives me the same exception message as before during CMake (assertion failed)... This happens with both _PC_53 and _PC_64!

[Maghoumi]

It fails on this line (obviously): _controlfp_s(&fpu_cw, _PC_53, _MCW_PC);

[Maghoumi]

Assertion failed message:

Debug Assertion Failed!

Program: ... File: amd64\ieee.c Line: 109

Expression: (mask&~(_MCW_DN|_MCW_EM|_MCW_RC))==0

For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)

[Maghoumi]

Also, I saw this:

https://svn.boost.org/trac/boost/ticket/4964

[Maghoumi]

Maybe this will be of help to you: http://stackoverflow.com/questions/2565693/floating-point-precision-in-visual-c

As you stated earlier, apparently MSVC does not support changing floating point precision in X64 mode. They link suggests a workaround.

[gabyx]

thanks a lot i will take a look :)

hm.. windows is anal (really)

can you try to compile the simple example with the flag "/fp:strict"

2 down vote

The complier option you want for Visual Studio is |/fp:strict| which is exposed in the IDE as |Project->Properties->C/C++->Code Generation->Floating Point Model|

https://msdn.microsoft.com/en-us/library/e7s85ffb.aspx

I think when doing this, I dont need to call _control_fps additionally because the extented precision is turned off for the whole library, (which is a bit stupid but the only option to make the things work correctly)

I think the example will still except (until I remove the , but by using fp:strict, the code will hopefully work as expected)

Does the dllimport shit work? If not then the preprocessor flag is not correctly recognized or set

On 11/27/2015 05:43 PM, Mehran Maghoumi wrote:

Maybe this will be of help to you: http://stackoverflow.com/questions/2565693/floating-point-precision-in-visual-c

As you stated earlier, apparently MSVC does not support changing floating point precision in X64 mode. They link suggests a workaround.

— Reply to this email directly or view it on GitHub https://github.com/gabyx/ApproxMVBB/issues/3#issuecomment-160172877.

[Maghoumi]

Let me try the newest commit. Will get back to you in a few minutes.

[Maghoumi]

Good news and bad news: Good: ApproxMVBB compiled on the first try! :) Bad: dllimport stuff work fine for "ApproxMVBB" but are still having issues with "ApproxMVBBExample".

There are a few other issues (with tests and KdTree example), but let me take a closer look.

[Maghoumi]

I will try to create a new pull request with some changes that need to be made.

[gabyx]

Jeah, the kdTreeExample, i need to look closer again at this, you said there is a stupid segfault, this should not be, I ran all stuff here with memory-sanitizer and address-sanitizers (gcc, clang feature) to make sure there is nothing going on wrong. Its crucial for me as well, I think its a stupid bug in the example not the library, I will see :-) I am using the kdTree stuff alot in my rigid body simulations, and not experienced a crash so far, "touch wood" lool

BR Gabriel

On 11/27/2015 06:26 PM, Mehran Maghoumi wrote:

Good news and bad news: Good: ApproxMVBB compiled on the first try! :) Bad: dllimport stuff work fine for "ApproxMVBB" but are still having issues with "ApproxMVBBExample".

There are a few other issues (with tests and KdTree example), but let me take a closer look.

— Reply to this email directly or view it on GitHub https://github.com/gabyx/ApproxMVBB/issues/3#issuecomment-160179707.

[Maghoumi]

Yeah... There is another thing! Apparently MSVC does not support type aliases AT ALL!!! I'm converting all using vvxx = yyzz to typedefs! Surprised how it compiled in the first place. Supported features are available here: http://wiki.apache.org/stdcxx/C++0xCompilerSupport

[Maghoumi]

Uhoh! Changing all using vvxx = yyzz may be impossible... You have a shitload of templated aliases in MyMatrixTypeDefs.hpp. Have to look into ways of making all of them templated typedefs instead. Why is everything OVERLY COMPLICATED in C/C++? :(

My guess is that MSVC has partial support for type aliases. That's why the whole thing compiled in the first place. However, if you use too many of them, it will screw up.

[gabyx]

wait, till you spent to much time on that,

MSVC is shit, believe me :-) always behind of the standard , thats why I do not support MSVC in the first place.

The problem with template using A = std::vector

is that they can not be replaced in c++0x (easily)

YOU might have forgotten the c++11 flag! I need to add this to the cmake, sorry!

On 11/27/2015 07:52 PM, Mehran Maghoumi wrote:

Uhoh! Changing all |using vvxx = yyzz| may be impossible... You have a shitload of templated aliases in |MyMatrixTypeDefs.hpp|. Have to look into ways of making all of them templated |typedef|s instead. Why is everything OVERLY COMPLICATED in C/C++? :(

— Reply to this email directly or view it on GitHub https://github.com/gabyx/ApproxMVBB/issues/3#issuecomment-160189661.

[Maghoumi]

Yes I know it's shit :D C# isn't so I still have no choice. No, C++11 flag was there! As I mentioned before, ALL MSVC compilers have C++11 support enabled by default ( so the flag is not required). I am now trying to obtain a copy of Visual Studio 2015. According to this page (https://msdn.microsoft.com/en-us/library/hh567368.aspx), more C++11 functionality is available with VS 2015. I was planning on upgrading to 2015 someday, might as well just do it today.

[gabyx]

thats a good idea anyway :-) but how did it compile before??

i dont get that?

On 11/27/2015 08:13 PM, Mehran Maghoumi wrote:

Yes I know it's shit :D C# isn't so I still have no choice. No, C++11 flag was there! As I mentioned before, ALL MSVC compilers have C++11 support enabled by default. I am now trying to obtain a copy of Visual Studio 2015. According to this page (https://msdn.microsoft.com/en-us/library/hh567368.aspx), more C++11 functionality is available with VS 2015. I was planning on upgrading to 2015 someday, might as well just do it today.

— Reply to this email directly or view it on GitHub https://github.com/gabyx/ApproxMVBB/issues/3#issuecomment-160192405.

[Maghoumi]

I don't know either, I'm guessing partial support...? Let's see how VS 2015 fares. Will try and report back.

[gabyx]

https://msdn.microsoft.com/en-US/library/hh567368.aspx#corelanguagetable

Alias templates

template using ....

is supported in MSVC studio 13

On 11/27/2015 08:13 PM, Mehran Maghoumi wrote:

Yes I know it's shit :D C# isn't so I still have no choice. No, C++11 flag was there! As I mentioned before, ALL MSVC compilers have C++11 support enabled by default. I am now trying to obtain a copy of Visual Studio 2015. According to this page (https://msdn.microsoft.com/en-us/library/hh567368.aspx), more C++11 functionality is available with VS 2015. I was planning on upgrading to 2015 someday, might as well just do it today.

— Reply to this email directly or view it on GitHub https://github.com/gabyx/ApproxMVBB/issues/3#issuecomment-160192405.

[gabyx]

So, sorry to bother again,

I though ApproxMVBB lib compiled, as you stated before, (was that not with MSVC? but with cygwin?)

so MSVC has problems with the using directives...?

On 11/27/2015 08:15 PM, Mehran Maghoumi wrote:

I don't know either, I'm guessing partial support...? Let's see how VS 2015 fares. Will try and report back.

— Reply to this email directly or view it on GitHub https://github.com/gabyx/ApproxMVBB/issues/3#issuecomment-160192805.

[Maghoumi]

I'm sorry for sending too many comments too fast! Let me elaborate:

I though ApproxMVBB lib compiled, as you stated before,

Yes. It compiled with MSVC as well as Cygwin.

so MSVC has problems with the using directives...?

I guess so! See, the problem is that the library compiles, but the tests don't. Remember I said I got errors for Vector3 being ambiguous? Back then, I used the fully qualified name and magically Vector3 was not ambiguous anymore. Now I'm getting similar errors with tests. Only this time, fully qualified names don't work. MVCC is bitching about getPointsFromFileBinary calls in ComputeApproxMVBBTests.hpp.

It throws internal compiler error (during compilation) !! Close inspection, reveals that it cannot find matching getPointsFromFileBinary function given the arguments. The matrix sent to that function is one of those using ... = .... directives. I tried changing them, but the function is still not recognized. I suspect it might be because of too many using .... = ..... and that is confusing the compiler somehow. I tried creating another function (with the same name, different signature) but still fails to compile with internal compiler error. That's why I thought trying it with VS2015 as well and see how it goes (because such error makes zero sense given that the function is clearly there and visible).

Does that make things a bit more clear?

[gabyx]

ooh i ve seen some error her in MyMAtrixTypeDefs

the usigned int M in *ApproxMVBB_DEFINE_MATRIX_TYPES_OF

*does not correspond to the ApproxMVBB::MyMatrix::MatrixStatDyn< PREC, M> (M = int here)

for example, that might cause shitty troubles I ve also experienced with clang lately,...

I try to make this consistent!

On 11/27/2015 08:24 PM, Mehran Maghoumi wrote:

I'm sorry for sending too many comments too fast! Let me elaborate:

I though ApproxMVBB lib compiled, as you stated before,
Yes. It compiled with MSVC as well as Cygwin.

so MSVC has problems with the using directives...?
I guess so! See, the problem is that the library compiles, but the
tests don't. Remember I said I got errors for |Vector3| being
ambiguous? Back then, I used the fully qualified name and
magically |Vector3| was not ambiguous anymore. Now I'm getting
similar errors with tests. Only this time, fully qualified names
don't work. MVCC is bitching about |getPointsFromFileBinary| calls
in |ComputeApproxMVBBTests.hpp|.

It throws |internal compiler error|!! Close inspection, reveals that it cannot find matching getPointsFromFileBinary function given the arguments. The matrix sent to that function is one of those |using ... = ....| directives. I tried changing them, but the functions is still not recognized. I suspect it might be because of too many |using .... = .....| and that is confusing the compiler somehow. I tried creating another function (with the same name, different signature) but still fails to compile with |internal compiler error|. That's why I thought trying it with VS2015 as well and see how it goes (because such error makes zero sense given that the function is clearly there and visible).

Does that make things a bit more clear?

— Reply to this email directly or view it on GitHub https://github.com/gabyx/ApproxMVBB/issues/3#issuecomment-160193489.