React-native: [META] Upgrading Folly

Created on 20 Jul 2018  路  15Comments  路  Source: facebook/react-native

For Discussion

The Folly version used in open source is very old. We're looking for volunteers interested in making the necessary changes to upgrade Folly in React Native.

Known Incompatibilities

This is in no way an exhaustive list, but be aware you'll need to tackle the following when upgrading Folly:

  • folly::Optional's has_value() doesn't exist
  • No template named 'Optional' in namespace 'folly' stuff
Follow Up Help Wanted Locked Discussion

Most helpful comment

@fkgozali Thank you for the review and landing.

Just for your information, in the Android PR, I wrote a folly patch in gradle to support gcc 4.9.
The patch works due to RN only includes partial folly library.
Unfortunately, folly does not support gcc 4.9 now and NDK only support gcc to 4.9.
We should use clang to support folly build, in case if we are going to import other parts of folly.

I am working on #21863 and hopefully we could use clang build soon.

All 15 comments

to upgrade Folly in React Native

Ideally, we'd want to pull the latest folly directly from https://github.com/facebook/folly - or at least use the latest version for each RN release - automatically.

This will involve updating/changing the integration with CocoaPods + gradle that react-native repo has today, e.g. making them run the build scripts already provided by folly repo, instead of making their own wrapper scripts / build steps.

I would like to volunteer to upgrade Folly in Android, and I think this experience will help me better learn C++.

Also it might be better to prepare RN for Clang and libc++ support, as it'll be the only compiler and STL in next NDK release. I tried to build RN with Clang and got many warnings, errors in Folly. So I think that it might be better to upgrade C++ or native tools beforehand, maybe merge https://github.com/facebook/react-native/pull/20357 which would land latest Android NDK version.

maybe it's better to switch to CMake to build jni code on Android, because boost, glob and folly supports it, but also many C++ libraries.

@dulmandakh Good idea. And with it we can also have better IDE support.

I have tried building with cmake
https://github.com/yinhangfeng/react-native/blob/0.53-stable-cmake/ReactAndroid/CMakeLists.txt
maybe have some reference value
i don't understand c++ but this does work.

for the convenience of testing I put all the libraries in ReactAndroid/third-party-ndk
Folly version 2018.02.05.00

problem:

  1. c++_shared conflict with jsc-android-buildscripts
    https://github.com/yinhangfeng/react-native/blob/0.53-stable-cmake/ReactAndroid/build.gradle#L255
  2. JSC_JSGlobalContextEnableDebugger does not exist https://github.com/yinhangfeng/react-native/blob/0.53-stable-cmake/ReactCommon/cxxreact/JSCExecutor.cpp#L224

@yinhangfeng could you please try to build master with CMake as is, or without bumping libraries. Once finished it will be easy to bump libraries to latest versions. Thank you.

I am going to upgrade folly and build the code with clang.
So far the build is passed with folly's patch https://github.com/facebook/folly/pull/953.
But there is still a bottleneck for runtime crash, that current prebuilt android-jsc (libjsc.so and libicu_common.so) are still built by GCC.
Both original JSC on jcenter and current upstream one are linked to libgnustl_shared.so.

It seems that the community maintained android-jsc builder could build JSC with clang.
I would clarify if there are any plans to upgrade android-jsc that built by clang.
or maybe @gengjiawen could share the steps that how you build the android-jsc at #18754.

I think that it might be better to start with clang then upgrade folly,
because clang is default toolchain for XCode so we'll have identical
toolchains for Folly upgrade.

But it's your choice, good luck 馃憤

I've tried before and the old folly does not support NDK with clang build.
This issue relates to this https://github.com/facebook/folly/issues/75.
That's why I upgrade folly directly.

Just create https://github.com/facebook/react-native/pull/21863 to show my changes in case if someone has interests.

I've merged both https://github.com/facebook/react-native/pull/21976 and https://github.com/facebook/react-native/pull/21977 - this should get us moving for the time being. However, I'd like to see if we can come up with a more scalable/automated way of upgrading Folly. For instance, right now we list out relevant files manually like so:

https://github.com/facebook/react-native/pull/21977/files#diff-ae2383f344153a01ce1b6130b453a8e1R5

This list usually changes release by release (not always, tho). I think to make it more maintainable (e.g. if we decide to upgrade it again 1 year from now), it would be great if somehow we can use whatever configuration folly repo already has. Perhaps there's no specific cmake/config for mobile builds atm, but maybe that's one way to approach this:

  • introduce mobile-only folly build config in folly repo
  • adjust gradle/cocoapods/xcode to execute such build script in the build step
  • all RN configs need to do is to point to a specific folly release

This will make upgrades much easier in the future. Thoughts?

Btw @Kudo, thank you for the PRs! They should unblock us for making Fabric C++ code compilable with gradle/cocoapods/xcode.

@fkgozali Thank you for the review and landing.

Just for your information, in the Android PR, I wrote a folly patch in gradle to support gcc 4.9.
The patch works due to RN only includes partial folly library.
Unfortunately, folly does not support gcc 4.9 now and NDK only support gcc to 4.9.
We should use clang to support folly build, in case if we are going to import other parts of folly.

I am working on #21863 and hopefully we could use clang build soon.

Just wanted to ask what is the status of this issue? Are we still looking for somebody to figure out a way to make folly upgrades easier in the future or are we alright with the current state of things?

@cpojer I think you can close it for now. Folly has been upgraded. Upgrade easier or migrate to CMake is another issue.

Was this page helpful?
0 / 5 - 0 ratings