weixin_39755003的博客

I had the same problem also on Ubuntu. I rebuilt Unreal Engine and Carla from the same terminal making sure

$ sudo update-alternatives --install /usr/bin/clang++ clang++ /usr/lib/llvm-3.9/bin/clang++ 100 $ sudo update-alternatives --install /usr/bin/clang clang /usr/lib/llvm-3.9/bin/clang 100

was set because at some point it had complained that Carla and Unreal Engine were compiled by different compilers. Solved it for me.

what we ended up doing is taking a different approach than federation.

basically we realized that our services are pretty consistently structured. so we decided to do was use a go script to generate our schema by reading all the schema files from the sub-services and then write that to the updated schema.

we then have code that automatically proxies requests to those subservices successfully.

from a practical standpoint it's pretty close to the stitching setup, but doesn't use the federation itself.

the above setup also means that we can define data loaders at our central api layer and easily embed them in sub-service queries without much work.

the one problem is that at the moment, when a sub-service is updated it doesn't automatically update the central api. instead that kicks off an automated process to rewrite that schema and open a pr against the central api.

it basically has made it that apollo federation is a bit less interesting to us.

-at-work is there an idea of having the gateway generated in gqlgen as well? perhaps as a plugin?

Wouldn't we just go with installing an application? I know Rei is working on that with BogInstaller. We do need an NCA generator though.

Try with modifying the function should_mitm (it's an inline so in a header file, don't remember which one).

I managed to build the PythonAPI by deleting the headers option in the boost build script Util\InstallersWin\install_boost.bat in my case with this option boost won't build the libboost_python lib

echo %FILE_N% Building... b2 -j%NUMBER_OF_ASYNC_JOBS%^ --layout=versioned^ --build-dir=.\build^ --with-system^ --with-filesystem^ --with-python^ --with-date_time^ architecture=x86^ address-model=64^ toolset=%TOOLSET%^ variant=release^ link=static^ runtime-link=shared^ threading=multi^ --prefix="%BOOST_INSTALL_DIR%"^ --libdir="%BOOST_LIB_DIR%"^ --includedir="%BOOST_INSTALL_DIR%"^ install

quote from http://boost.2283326.n4.nabble.com/doc-b2-headers-td4702968.html

b2 headers is not really intended for end users. It's only relevant when working from git as the packaged releases have all the headers moved into boost/ to begin with.

It would be nice to be able to implement an interface to manage the control of pedestrians - especially to generate corner cases.