Windows & wxWidgets platform

[tehKaiN]

Hi there,

I've ported tangram-es to Windows during this weekend and I'd like to contribute changes, but I'm not quite certain how I should do this.

Although I've tried to keep it clean as possible, some changes may be breaking for other platforms. Unfortunately I don't have environment to test other platforms, so I guess direct merge to master would be inappropriate 'cuz I won't be able to fix everything by myself.

My windows branch is here: https://github.com/tehKaiN/tangram-es/tree/platform-windows

Also, I'd like to create tangram-es wxWidgets widget. After it's done, should I contribute it later to this repo as additional platform or keep it on separate repo?

[matteblair]

Hey this looks great! 👏

Let's start with the Windows platform, I'll have more questions about wxWidgets I think.

I just created a branch in this repo called windows-platform: https://github.com/tangrams/tangram-es/tree/windows-platform. You should be able to make a pull request from the branch in your fork onto our branch. Then we can test it out and quickly adjust anything that might break other platforms :)

Question about your build configuration: It looks like you have CMake searching for libCurl using findpackage. As far as I know Curl is not typically installed on Windows, did you have to install Curl in a particular way for CMake to be able to find it?

[tehKaiN]

Ok, here it is. As of curl, I've added it's path to CMAKE_PREFIX_PATH as findpackage uses it to find packages. :)

[tehKaiN]

So I did some work on wxWidgets support. https://github.com/tehKaiN/tangram-es/tree/platform-wxwidgets

Perhaps it would be wise to just have DLL platform for use with any other framework/lib/whatever, but still linux/rpi platforms are more like app stubs to begin development with.

wxtangram.cpp/.h implements wxTangram widget which inherits from wxGLCanvas widget. Main file containing app startup and widget usage is yet to be commited. This is still far from complete 'cuz many basic event handlers analogous to glfwApp are missing. Honestly, IDK if they should be included or externally implemented by devs, but I guess it's not really gonna be immutable and read-only map control implementation, but just app stub.

[tehKaiN]

So right now I'm trying to compile it using Windows ABI since I have to link my project with msvc-compiled DLLs. MSVC is too poor for compiling tangram-es, since it doesn't support many cpp features. Tested under build tools 2015 and 2017 (aka 14.0 and 14.1).

My current approach is under llvm/clang 5.0. I can't really force CMake to use clang on windows, since it tries to talk to it the same way as msvc's cl compiler when defined in CMAKE_C_COMPILER and CXX too. There is clang-cl which accepts same args as cl but I get lots of errors, especially in variant.hpp and geojscon-vt-cpp regarding access to private constructors. I guess clang fails to RVO them.

Also, css-color-parser dependency needed updating since latest commit fixes msvc builds with one missing #include.

I'm stuck at 76%. Right now stuff which is blocking me:

In file included from D:\prg\_git\tangram-es\core\src\data\clientGeoJsonSource.cpp:15:
D:\prg\_git\tangram-es\core\deps\geojson-vt-cpp\geojson.hpp\include\mapbox/geojson_impl.hpp(297,20):  error: no matching
      member function for call to 'PushBack'
            result.PushBack(operator()(vector[i]), allocator);
            ~~~~~~~^~~~~~~~
D:\prg\_git\tangram-es\core\deps\variant/include/mapbox/variant.hpp(339,16):  note: in instantiation of function
      template specialization
      'mapbox::geojson::to_coordinates_or_geometries::operator()<mapbox::geometry::geometry<double> >' requested here
        return f(unwrapper<T>::apply_const(v.template get_unchecked<T>()));
               ^
D:\prg\_git\tangram-es\core\deps\variant/include/mapbox/variant.hpp(317,51):  note: in instantiation of member function
      'mapbox::util::detail::dispatcher<mapbox::geojson::to_coordinates_or_geometries,
      mapbox::geometry::geometry<double>, rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::CrtAllocator>,
      mapbox::geometry::geometry_collection<double, std::vector> >::apply_const' requested here
            return dispatcher<F, V, R, Types...>::apply_const(v, std::forward<F>(f));
                                                  ^
D:\prg\_git\tangram-es\core\deps\variant/include/mapbox/variant.hpp(317,51):  note: in instantiation of member function
      'mapbox::util::detail::dispatcher<mapbox::geojson::to_coordinates_or_geometries,
      mapbox::geometry::geometry<double>, rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::CrtAllocator>,
      mapbox::geometry::multi_polygon<double, std::vector>, mapbox::geometry::geometry_collection<double, std::vector>
      >::apply_const' requested here
D:\prg\_git\tangram-es\core\deps\variant/include/mapbox/variant.hpp(317,51):  note: in instantiation of member function
      'mapbox::util::detail::dispatcher<mapbox::geojson::to_coordinates_or_geometries,
      mapbox::geometry::geometry<double>, rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::CrtAllocator>,
      mapbox::geometry::multi_line_string<double, std::vector>, mapbox::geometry::multi_polygon<double, std::vector>,
      mapbox::geometry::geometry_collection<double, std::vector> >::apply_const' requested here
D:\prg\_git\tangram-es\core\deps\variant/include/mapbox/variant.hpp(317,51):  note: in instantiation of member function
      'mapbox::util::detail::dispatcher<mapbox::geojson::to_coordinates_or_geometries,
      mapbox::geometry::geometry<double>, rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::CrtAllocator>,
      mapbox::geometry::multi_point<double, std::vector>, mapbox::geometry::multi_line_string<double, std::vector>,
      mapbox::geometry::multi_polygon<double, std::vector>, mapbox::geometry::geometry_collection<double, std::vector>
      >::apply_const' requested here
D:\prg\_git\tangram-es\core\deps\variant/include/mapbox/variant.hpp(317,51):  note: in instantiation of member function
      'mapbox::util::detail::dispatcher<mapbox::geojson::to_coordinates_or_geometries,
      mapbox::geometry::geometry<double>, rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::CrtAllocator>,
      mapbox::geometry::polygon<double, std::vector>, mapbox::geometry::multi_point<double, std::vector>,
      mapbox::geometry::multi_line_string<double, std::vector>, mapbox::geometry::multi_polygon<double, std::vector>,
      mapbox::geometry::geometry_collection<double, std::vector> >::apply_const' requested here
D:\prg\_git\tangram-es\core\deps\variant/include/mapbox/variant.hpp(317,51):  note: in instantiation of member function
      'mapbox::util::detail::dispatcher<mapbox::geojson::to_coordinates_or_geometries,
      mapbox::geometry::geometry<double>, rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::CrtAllocator>,
      mapbox::geometry::line_string<double, std::vector>, mapbox::geometry::polygon<double, std::vector>,
      mapbox::geometry::multi_point<double, std::vector>, mapbox::geometry::multi_line_string<double, std::vector>,
      mapbox::geometry::multi_polygon<double, std::vector>, mapbox::geometry::geometry_collection<double, std::vector>
      >::apply_const' requested here
D:\prg\_git\tangram-es\core\deps\variant/include/mapbox/variant.hpp(869,55):  note: in instantiation of member function
      'mapbox::util::detail::dispatcher<mapbox::geojson::to_coordinates_or_geometries,
      mapbox::geometry::geometry<double>, rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::CrtAllocator>,
      mapbox::geometry::point<double>, mapbox::geometry::line_string<double, std::vector>,
      mapbox::geometry::polygon<double, std::vector>, mapbox::geometry::multi_point<double, std::vector>,
      mapbox::geometry::multi_line_string<double, std::vector>, mapbox::geometry::multi_polygon<double, std::vector>,
      mapbox::geometry::geometry_collection<double, std::vector> >::apply_const' requested here
        return detail::dispatcher<F, V, R, Types...>::apply_const(v, std::forward<F>(f));
                                                      ^
D:\prg\_git\tangram-es\core\deps\geojson-vt-cpp\geojson.hpp\include\mapbox/geojson_impl.hpp(390,19):  note: in
      instantiation of function template specialization 'mapbox::util::variant<mapbox::geometry::point<double>,
      mapbox::geometry::line_string<double, std::vector>, mapbox::geometry::polygon<double, std::vector>,
      mapbox::geometry::multi_point<double, std::vector>, mapbox::geometry::multi_line_string<double, std::vector>,
      mapbox::geometry::multi_polygon<double, std::vector>, mapbox::geometry::geometry_collection<double, std::vector>
      >::visit<mapbox::geojson::to_coordinates_or_geometries, mapbox::geometry::geometry<double>,
      rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
        geometry::visit(element, to_coordinates_or_geometries { allocator }),
                  ^
D:\prg\_git\tangram-es\core\deps\rapidjson/document.h(1563,19):  note: candidate function not viable: no known
      conversion from 'mapbox::geojson::rapidjson_value' (aka 'GenericValue<UTF8<>, rapidjson::CrtAllocator>') to
      'rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::CrtAllocator>::StringRefType'
      (aka 'GenericStringRef<char>') for 1st argument
    GenericValue& PushBack(StringRefType value, Allocator& allocator) {
                  ^
D:\prg\_git\tangram-es\core\deps\rapidjson/document.h(1586,5):  note: candidate template ignored: substitution failure
      [with T = rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::CrtAllocator>]: no type named 'Type' in
      'rapidjson::internal::DisableIf<rapidjson::internal::OrExpr<rapidjson::internal::IsPointer<rapidjson::GenericValue<rapidjson::UTF8<char>,
      rapidjson::CrtAllocator> >, rapidjson::internal::IsGenericValue<rapidjson::GenericValue<rapidjson::UTF8<char>,
      rapidjson::CrtAllocator> > >, rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::CrtAllocator> &>'
    PushBack(T value, Allocator& allocator) {
    ^

Any ideas & help would be appreciated ;)

[tehKaiN]

So I've traced some problem with clang (not msvc compatible clang-cl), which doesn't occur with g++:

clang -c \path\to\tangram-es\core\src\data\clientGeoJsonSource.cpp <INCLUDES> -std=c++17 # not working
g++ -c \path\to\tangram-es\core\src\data\clientGeoJsonSource.cpp <INCLUDES> -std=c++17 # working

Includes as follows:

-I\path\to\tangram-es\platforms\common\glfw\include
-I\path\to\tangram-es\platforms\common
-I\path\to\curl-7.55.1\builds\libcurl-vc-x86-release-static-ipv6-sspi-winssl\include
-I\path\to\tangram-es\core\src
-I\path\to\tangram-es\core\include\tangram
-I\path\to\tangram-es\core\generated
-I\path\to\tangram-es\core\deps
-I\path\to\tangram-es\core\deps\glm
-I\path\to\tangram-es\core\deps\earcut\include
-I\path\to\tangram-es\core\deps\isect2d\include
-I\path\to\tangram-es\core\deps\hash-library
-I\path\to\tangram-es\core\deps\mapbox
-I\path\to\tangram-es\core\deps\pbf
-I\path\to\tangram-es\core\deps\rapidjson
-I\path\to\tangram-es\core\deps\sdf
-I\path\to\tangram-es\core\deps\SQLiteCpp
-I\path\to\tangram-es\core\deps\stb
-I\path\to\tangram-es\core\deps\miniz
-I\path\to\tangram-es\core\deps\geojson-vt-cpp\geometry.hpp\include
-I\path\to\tangram-es\core\deps\geojson-vt-cpp\geojson.hpp\include
-I\path\to\tangram-es\core\deps\geojson-vt-cpp\include
-I\path\to\tangram-es\core\deps\double-conversion\include
-I\path\to\zlib\zlib-1.2.11
-I\path\to\tangram-es\core\deps\duktape
-I\path\to\tangram-es\core\deps\css-color-parser-cpp
-I\path\to\tangram-es\core\deps\yaml-cpp\include
-I\path\to\tangram-es\core\deps\alfons\src
-I\path\to\tangram-es\core\deps\alfons\src\logger
-I\path\to\tangram-es\core\deps\alfons\src\linebreak
-I\path\to\tangram-es\core\deps\harfbuzz-icu-freetype\harfbuzz-generated
-I\path\to\tangram-es\core\deps\harfbuzz-icu-freetype\harfbuzz\src
-I\path\to\tangram-es\core\deps\harfbuzz-icu-freetype\freetype\include
-I\path\to\tangram-es\core\deps\harfbuzz-icu-freetype\harfbuzz\src\hb-ucdn
-I\path\to\tangram-es\core\deps\harfbuzz-icu-freetype\icu\common
-I\path\to\tangram-es\core\deps\harfbuzz-icu-freetype\icu\stubdata
-I\path\to\tangram-es\core\deps\harfbuzz-icu-freetype\icu\common\unicode
-I\path\to\tangram-es\core\deps\SQLiteCpp\include
-I\path\to\tangram-es\core\deps\SQLiteCpp\sqlite3 

[matteblair]

Interesting, this error doesn't look familiar to me. It looks like you're compiling with -std=c++17, have you tried -std=c++14? I don't think our code requires any c++17 features.

What was the problem with MSVC? If possible I'd rather tweak our code to work with Microsoft's tools, since most Windows users would prefer that to Clang.

[tehKaiN]

Yup, tried with c++14, gnu++1y, gnu++1z, everything. C++17 makes some copy elision compulsory, which I thought will help clang, because there are lots of problems with returning by copy using private constructors - something that GCC optimizes away.

You don't want to make this code compatible with MSVC - their compiler is rotten, has it's own quirks, oh and forget about variadic templates. Even MS bundles clang with their build tools so that one may use it for compiling too new projects. They bundle old version though (3.8, llvm.org has 5.0).

I've spent 4 days trying to compile tangram-es using non-gcc so if you have any other questions - ask away, prob'ly been there. ;)

[postaistvan]

Hello,

I've tried to compile your code on 64bit Windows 7 using the following Mingw: http://mingw-w64.org/doku.php/download/mingw-builds

I get a lot of the following error while building it:

D:/projects/OSMapp/tangram-es-tehkain/tangram-es/core/deps/glm/glm/detail/type vec4_simd.inl:156:11: error: 'struct glm::tvec4<float, (glm::precision)5>' has n o member named 'data' Result.data = mm_mul_ps(a.data, mm_rcp_ps(b.data)); ^~~~

Did you encounter anything like this while working on it?

Thank you in advance!

[tehKaiN]

Hi there,

My project needed rebuilding of tangram dependency, but my working branches became nasty. Since my last contributions I've learned a bit more about git, I've gave it another go - this time I'll rebase it on latest master periodically until it gets merged.

Here's a branch based on most recent master. Sample app runs and I've even left a decent README with build instructions, but there's a problem - my app closes without any backtrace and error after 2s just in the middle of fetching fonts from the net - in the middle of urlClient logging, even if I enforce urlClient count to 1, thus it must be something else than curl. Any help would be appreciated. ;)

BTW. Why ain't such popular OS still officially supported?

[tallytalwar]

@tehKaiN Can you please put a Pull Request for your work on this? It will be good to review it using github's review system. Thanks

[tehKaiN]

I've added #1812.

[tehKaiN]

So I've run it in gdb and this time I've added break exit and I get this:

ader.cpp:1745: Can't find data source touch for layer touch
[Switching to Thread 5548.0xf5c]

Thread 10 hit Breakpoint 1, 0x760b5df5 in msvcrt!_exit () from C:\WINDOWS\System32\msvcrt.dll
(gdb) bt
#0  0x760b5df5 in msvcrt!_exit () from C:\WINDOWS\System32\msvcrt.dll
#1  0x760ab4d8 in msvcrt!abort () from C:\WINDOWS\System32\msvcrt.dll
#2  0x0073b9aa in uw_init_context_1 (context=context@entry=0x7dceef0, outer_cfa=outer_cfa@entry=0x7dcf0d0,
    outer_ra=0x977b9c <__cxa_throw+92>) at ../../../../../src/gcc-7.3.0/libgcc/unwind-dw2.c:1579
#3  0x0073bfbe in _Unwind_RaiseException (exc=0x715e228) at C:/mingw730/src/gcc-7.3.0/libgcc/unwind.inc:88
#4  0x00977b9c in __cxa_throw ()
#5  0x007f1b83 in YAML::as_if<bool, void>::operator() (this=0x7dcf15c)
    at C:/prg/_git/tangram-es/core/deps/yaml-cpp/include/yaml-cpp/node/impl.h:142
#6  0x007f0e58 in YAML::Node::as<bool> (this=0x7dcf314)
    at C:/prg/_git/tangram-es/core/deps/yaml-cpp/include/yaml-cpp/node/impl.h:162
#7  0x004580e8 in Tangram::getBool (node=..., value=@0x7dcf21f: false, name=0x0)
    at C:\prg\_git\tangram-es\core\src\util\yamlHelper.cpp:147
#8  0x00424ee6 in Tangram::SceneLoader::generatePredicate (_node=..., _key="type")
    at C:\prg\_git\tangram-es\core\src\scene\sceneLoader.cpp:1378
#9  0x004249d6 in Tangram::SceneLoader::generateFilter (_filter=..., scene=...)
    at C:\prg\_git\tangram-es\core\src\scene\sceneLoader.cpp:1345
#10 0x00427dbf in Tangram::SceneLoader::loadSublayer (layer=..., layerName="touch:line", scene=
    std::shared_ptr (count 6, weak 0) 0x71022e8) at C:\prg\_git\tangram-es\core\src\scene\sceneLoader.cpp:1710
#11 0x0042805c in Tangram::SceneLoader::loadSublayer (layer=..., layerName="touch",
    scene=std::shared_ptr (count 6, weak 0) 0x71022e8) at C:\prg\_git\tangram-es\core\src\scene\sceneLoader.cpp:1723
#12 0x004286d5 in Tangram::SceneLoader::loadLayer (layer=..., scene=std::shared_ptr (count 6, weak 0) 0x71022e8)
    at C:\prg\_git\tangram-es\core\src\scene\sceneLoader.cpp:1763
#13 0x0041af56 in Tangram::SceneLoader::applyConfig (_platform=std::shared_ptr (count 10, weak 0) 0x70a6958,
    _scene=std::shared_ptr (count 6, weak 0) 0x71022e8) at C:\prg\_git\tangram-es\core\src\scene\sceneLoader.cpp:264
#14 0x00419730 in Tangram::SceneLoader::loadScene (_platform=std::shared_ptr (count 10, weak 0) 0x70a6958,
    _scene=std::shared_ptr (count 6, weak 0) 0x71022e8, _updates=std::vector of length 1, capacity 1 = {...})
    at C:\prg\_git\tangram-es\core\src\scene\sceneLoader.cpp:78
#15 0x0040d5f7 in Tangram::Map::<lambda()>::operator()(void) const (__closure=0x710a520)
    at C:\prg\_git\tangram-es\core\src\map.cpp:269
#16 0x004114b1 in std::_Function_handler<void(), Tangram::Map::loadSceneAsync(std::shared_ptr<Tangram::Scene>, const std::vector<Tangram::SceneUpdate>&)::<lambda()> >::_M_invoke(const std::_Any_data &) (__functor=...)
    at C:/prg/kompilatory/mingw-w64/mingw32/lib/gcc/i686-w64-mingw32/7.3.0/include/c++/bits/std_function.h:316
#17 0x0084af9a in std::function<void ()>::operator()() const (this=0x7dcfdcc)
    at C:/prg/kompilatory/mingw-w64/mingw32/lib/gcc/i686-w64-mingw32/7.3.0/include/c++/bits/std_function.h:706
#18 0x007917ed in Tangram::AsyncWorker::run (this=0x70beb40) at C:/prg/_git/tangram-es/core/src/util/asyncWorker.h:47
#19 0x0094f9cf in std::__invoke_impl<void, void (Tangram::AsyncWorker::*)(), Tangram::AsyncWorker*> (
    __f=@0x70bede8: (void (Tangram::AsyncWorker::*)(Tangram::AsyncWorker * const)) 0x791734 <Tangram::AsyncWorker::run()>, __t=@0x70bede4: 0x70beb40)
    at C:/prg/kompilatory/mingw-w64/mingw32/lib/gcc/i686-w64-mingw32/7.3.0/include/c++/bits/invoke.h:73
#20 0x0096cb63 in std::__invoke<void (Tangram::AsyncWorker::*)(), Tangram::AsyncWorker*> (
    __fn=@0x70bede8: (void (Tangram::AsyncWorker::*)(Tangram::AsyncWorker * const)) 0x791734 <Tangram::AsyncWorker::run()>, __args#0=@0x70bede4: 0x70beb40)
    at C:/prg/kompilatory/mingw-w64/mingw32/lib/gcc/i686-w64-mingw32/7.3.0/include/c++/bits/invoke.h:95
#21 0x008d86f2 in std::thread::_Invoker<std::tuple<void (Tangram::AsyncWorker::*)(), Tangram::AsyncWorker*> >::_M_invoke<0u, 1u> (this=0x70bede4)
    at C:/prg/kompilatory/mingw-w64/mingw32/lib/gcc/i686-w64-mingw32/7.3.0/include/c++/thread:234
#22 0x008d8736 in std::thread::_Invoker<std::tuple<void (Tangram::AsyncWorker::*)(), Tangram::AsyncWorker*> >::operator() (this=0x70bede4) at C:/prg/kompilatory/mingw-w64/mingw32/lib/gcc/i686-w64-mingw32/7.3.0/include/c++/thread:243
#23 0x008d805e in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (Tangram::AsyncWorker::*)(), Tangram::AsyncWorker*> > >::_M_run (this=0x70bede0)
    at C:/prg/kompilatory/mingw-w64/mingw32/lib/gcc/i686-w64-mingw32/7.3.0/include/c++/thread:186

So I get crash from this sceneLoader line: auto sublayer = loadSublayer(layer.second, name, scene); which gets into loadSubLayer() for touch:line which calls as_if<bool, void> and throws

template <typename T>
struct as_if<T, void> {
  explicit as_if(const Node& node_) : node(node_) {}
  const Node& node;

  T operator()() const {
    if (!node.m_pNode)
      throw TypedBadConversion<T>(node.Mark());

    T t;
    if (convert<T>::decode(node, t))
      return t;
    throw TypedBadConversion<T>(node.Mark()); // <---- HERE
  }
};

all of that using master's scene.yaml generated into bin folder.

EDIT: I've traced it to this point:

layers:
    touch:
        data: { source: touch }
        line:
          filter: { type: line }

generateFilter() call goes here:

            } else if (key == "all") {
                f = generateAllFilter(node, scene);
            } else {
                f = generatePredicate(node, key); // <--- HERE, key = "type"
            }

[matteblair]

@tehKaiN It's weird that tangram would be crashing at this point - as you can see from the line printed in the stack trace our code is explicitly catching an exception that encompasses the thrown exception (https://github.com/tangrams/tangram-es/blob/master/core/src/util/yamlHelper.cpp#L147). Maybe your compiler needs a flag to correctly support exception handling?

[tehKaiN]

I did a quick check with:

#include <iostream>

int main(void) {
    try {
        throw(new std::exception());
    }
    catch(...) {
        std::cout << "Catched" << std::endl;
    }
    return 0;
}

and compiling using g++ main.c and everything works fine, so unless CMake is putting some flags to disable exceptions, everything should work fine. I hope that it's not some kind of MinGW bug or behavior dependent on installed MinGW version, as there are SJLJ and DWARF exception handling variants.

I don't clearly see exception type in my stacktrace, so perhaps exception is thrown but of other type?

[tehKaiN]

Okay, so exceptions support was a good trail. I've reinstalled mingw-w64 to i686-8.1.0-posix-sjlj-rt_v6-rev0 and it works - it looks like some kind of DWARF2 problem.

I'm currently building by creating build/windows folder and calling cmake from there. I see that there's makefile in root dir, so I guess I should add windows support to it too?

[tehKaiN]

So I've added a bit of Windows support for main Makefile, but it made it ugly. Windows cmd console behaves differently than everything else in terms of creating and deleting directories, so I had to add basic host detection and substitute mkdir/rm cmds with vars.

make clean-windows works, but it uses back-slashed path (build\windows) since forward slash doesn't work well with rmdir. This is the reason why make clean doesn't work: rest of clean- targets use forward-slashed path. One way to overcome this is to replace slashes in host platform-dependent way. If you feel fine with such change, I'll try to apply it.

Another potential fix is to put notice in README.md that to successfully build you need linux cmd tools which come with MSYS2, Windows Ubuntu subsystem or are an optional install in git-scm.

I guess such incompatibilities are one of the main reasons why CMake was invented. Perhaps it would be wise to scrap main makefile altogether and just instruct users to create build folder and call appropriate cmake .. from there.

Apart from it, what else is required to merge it into master? Currently we have:

• Working glfw app
• Platform's README.md with build instructions
• a bit of main Makefile support

Also, I've noticed that linux platform uses fontconfig as source of system fonts, which is nonexistent on Windows. Currently Windows app uses hardcoded font names as Linux did before introducing fontconfig. Is it okay or does it need more work?

[tehKaiN]

I've dusted off my wxWidgets Tangram widget code - I'll create pull request after Windows gets merged.

[tehKaiN]

In relation to #1812

I'm syncing my code with latest stuff and I have it up and running, but I get crashes here and there.

Is it me or does it look like label vector getting reallocated during sorting? ;) Have you stumbled upon something like that or have I caused it?

EDIT: Nah, mutex haven't solved it. I've also tried do mitigate huge-ass numbers by putting some if but it didn't worked:

[tallytalwar]

We have not touched label collision code in a while. But yes there seems to be a memory corruption issue on master right now we are investigating, which might be causing this.