How to eliminate fonts which are not used to reduce release build - react-native

Apk Analyzer
package.json includes
"rnpm": {
"assets": [
"./assets/fonts"
]
}
"react-native-vector-icons": "9.2.0",

You can go in library and comment the line if needed and patch library so that fonts won't be included neither in iOS or Android builds
That's what I did when I faced issue with same library :)

Related

CMake: how to set -B parameter (path-to-build) inside CMakeLists.txt? [duplicate]

This question already has answers here:
Specifying build directory within CMakeLists file
(2 answers)
Closed 10 months ago.
Is there some system variable in CMakeLists.txt to set all build temporary files to specified dir (CMakeCache, CMakeFiles, build artifacts, etc)? This can be done using command line parameter -B (path-to-build), but I need it inside CMakeLists.txt to set default dir for all files, which are not-tracked with git
If you specify a build directory via command line, it always overwrites any values from other sources.
You can achieve something similar to the effect you desire using cmake presets, but it's a relatively new addition (= version 3.19) to the cmake features and it doesn't specify the build directory inside the CMakeLists.txt file, but inside a CMakePresets.json file.
The presence of the file won't break the project for older cmake versions, but the initial configuration becomes less convenient.
CMakePresets.json (place next to the toplevel CMakeLists.txt)
{
"version": 1,
"cmakeMinimumRequired": {
"major": 3,
"minor": 19,
"patch": 0
},
"configurePresets": [
{
"name": "makefiles",
"displayName": "Default configuration",
"description": "Default config",
"generator": "Unix Makefiles",
"binaryDir": "../build"
}
]
}
This allows you to choose the default build location as a sibling directory of the source dir using
cmake --preset makefiles .
This uses the sibling directory build of the source directory as the binary directory.
You can use CMake presets for it. You use the binaryDir property and never again you need to provide the -B argument as long as you use presets to generate your project files and/or build your project.

Android lint AnnotationProcessorOnCompilePath with ButterKnife

After upgrading to latest Android gradle plugin:
classpath 'com.android.tools.build:gradle:3.6.1'
Android lint (./gradlew lint) getting following warning:
Warning: Add annotation processor to processor path using annotationProcessor instead of implementation [AnnotationProcessorOnCompilePath]
implementation 'com.jakewharton:butterknife:10.2.1'
My app/build.gradle file:
dependencies {
[...]
implementation 'com.jakewharton:butterknife:10.2.1'
kapt 'com.jakewharton:butterknife-compiler:10.2.1'
}
Which is correct according to ButterKnife documentation: https://github.com/JakeWharton/butterknife#download
Hacky solution would be to suppress //noinspection AnnotationProcessorOnCompilePath for ButterKnife.
But how to fix this problem properly?
Apparently, it's a bug on Lint side. They say it will be fixed on the upcoming 4.0 release.
Source:
https://issuetracker.google.com/issues/140881211

compile optimized C++ for debug build in Android Studio

I want to set jniDebuggable to false in Android Studio's debug version, but it seems that it doesn't work even I set like this:
debug {
jniDebuggable false
}
Since my JNI debug build is slow when running, I want to use the release build (faster than debug) when I debug my Java code.
Who can tell me how to do?
As stated in the comments under the question post by #Alex Cohn, and adapted from this answer he wrote to "adding "-O0" to cppFlags fails to disable clang compile optimization in android studio", you could do:
android {
defaultConfig {
externalNativeBuild {
cmake {
arguments '-DCMAKE_BUILD_TYPE:STRING=Release'
That's if you don't need actual debug support for the native side of things (i.e. if by "debug", you really just mean running and testing your code without a debugger). If you do, use RelWithDebInfo instead of Release, which creates an optimized build with debug symbols (see here for CMake docs on build out-of-box-defined types).
See here for docs on Android NDK's CMake Guide, and here for docs on ExternalNativeBuildOptions.

Spurious targets when installing a software with CMake

I wrote a software whose configuration, building and installation are performed by means of some CMake files. This software is developped in a continuous integration process based on unit and functional tests. I noticed that targets corresponding to these tests are built during the installation step. It is not necessary at all and I would like to understand how to prevent CMake from doing it.
After having typed
make install
I get the following output:
[ 7%] Built target arpack
[ 15%] Built target boost
[ 23%] Built target eigen
[ 31%] Built target yamlcpp
[ 34%] Built target simol-core
[ 36%] Built target simol-quantchem
[ 80%] Built target simol-statphys
[ 88%] Built target gtest
[ 91%] Built target simol_test_unit
[ 92%] Built target simol_test_functional
[ 93%] Built target test_bichainfpu
[ 94%] Built target test_dpde
[ 95%] Built target test_fluid
[ 96%] Built target test_galerkin
[ 97%] Built target test_hamiltonian
[ 98%] Built target test_langevin
[ 99%] Built target test_rotor
[100%] Built target test_trichain
The steps from 88% to 100% are definitively spurious since I do not install any tests but only the core of the software and its modules. For example, the CMake command which installs simol-statphys (80%) is
INSTALL(TARGETS simol-statphys ARCHIVE DESTINATION lib)
I have a similar command for simol-core (34%) and simol-quantchem (36%). I can understand why previous targets are built (arpack, boost, eigen, yamlcpp) because the modules of the software depend on these external libraries. But they do not depend on the tests. The reverse is true: tests obviously depend on the module. But it does not make sense to me why they should be involved in the installation step. Of course, there is no call to the INSTALL command for the tests. These tests are only defined like this:
ADD_EXECUTABLE(test_galerkin ${CMAKE_SOURCE_DIR}/test/functional/statphys/galerkin/TestGalerkin.cpp)
TARGET_LINK_LIBRARIES(test_galerkin simol-statphys)
Does anybody know what is happening here?
CMake doesn't track dependency between installed targets and their built counterpairs. Instead, whole install (pseudo-)target is made dependent from all one.
So, whatever is built during make all is built also on make install.
If you don't want to build tests on make install, exclude them from make all. The simplest way to do this is using option EXCLUDE_FROM_ALL in add_executable() invocation:
ADD_EXECUTABLE(test_galerkin EXCLUDE_FROM_ALL ...)

Sublime Text 2. How do I create project for Objective-C code?

How do I create a project in Sublime text that can handle compiling and linking Objective-C files?
I can build and run a single objective-c file. I am pulling my hair out trying to compile and link multiple files. Is a project file the answer? I'm stumped.
A project file is useful for organizing all your files, and I definitely recommend using them for each of your projects, but a build system will do what you're looking for here. These are very flexible and powerful systems, especially when you take full advantage of the options and variables listed in the Build System Reference. A fairly simple example to compile (and optionally run) a single file is below (modified from this gist for semi-unique output file names):
{
"cmd": ["bash", "-c", "clang -lobjc -framework Cocoa -framework Carbon -o /tmp/${file_name}_sublime_build $file"],
"file_regex": "^(.*?):([0-9]+):([0-9]+): (.*)",
"selector": "source.objc",
"variants": [
{
"name": "Run",
"cmd": ["bash", "-c", "clang -lobjc -framework Cocoa -framework Carbon -o /tmp/${file_name}_sublime_build $file && /tmp/${file_name}_sublime_build"]
}
]
}
For multiple class files, probably the best option is to put together a simple Makefile and use Sublime's built-in Make build system:
{
"cmd": ["make"],
"file_regex": "^(..[^:]*):([0-9]+):?([0-9]+)?:? (.*)$",
"working_dir": "${project_path:${folder:${file_path}}}",
"selector": "source.makefile",
"variants":
[
{
"name": "Clean",
"cmd": ["make", "clean"]
}
]
}
This way, you don't need to have a customized .sublime-build file for each project (although you might be able to get away with it if they're similar enough), all you'd need to do is create a Makefile, set the appropriate project variables, and you're good to go.
Good luck!