Build fails with "Argument list too long: recursive header expansion failed"
Opened this issue · 5 comments
Hi, these lines are causing my build to fail:
FRAMEWORK_SEARCH_PATHS = "${PROJECT_DIR}/../../../ios/Pods/**"
and
HEADER_SEARCH_PATHS = (
...
"$(SRCROOT)/../../react-native/React/**"
I get the "Argument list too long: recursive header expansion failed" error. If I change these two settings in xcode to "non-recursive" instead of "recursive", the build succeeds, until the next time I restart my mac and then the build fails with the same error again.
Are these lines actually used? If not, would you accept a PR that removes them?
Thanks very much.
I believe these lines were added automatically by https://github.com/react-community/create-react-native-app. I can't immediately confirm though since I'm using npm 5.x and that project only supports npm 4.
Thanks for the reply, I'm not sure I understand though. I've never used create-react-native-app
, and also these lines (and the accompanying build failure) are reinstated every time I run a yarn
command in my project, which suggests to me that the lines in question, which are in the react-native-smooch
codebase, are to blame.
Or do you mean that create-react-native-app
was used in the development of react-native-smooch
somehow?
Just to be clear: the issue is that whenever react-native-smooch
is installed (i.e. whenever a yarn
command is executed in my project), I can no longer build my app until I change the following settings from "recursive" to "non-recursive":
↑ This is the RCTSmooch target in Xcode.
↑↓ These are the search paths that need to be changed from "recursive" to "non-recursive".
I have traced the source of these settings to these lines in the react-native-smooch
codebase: https://github.com/smooch/react-native-smooch/blob/master/ios/RCTSmooch.xcodeproj/project.pbxproj#L201-L234
Sorry, I meant react-native-create-library not create-react-native-app. But yes I believe that tool was used in #13 to bootstrap this repo as a distributable library, and the project file was automatically generated there.
Ah ok, didn't know about that lib. Do you guys have a testing process set up for this package? I'd like to submit a PR to change those two lines, but I have no way of knowing if it will screw everything up for consumers of this package.
We haven't been able to reproduce this issue on our side so we wouldn't really be able to verify if your fix is working as intended. Maybe you could make your changes in a fork and use that instead of the official package, until we see more occurrences of this issue from different users?