- 
                Notifications
    You must be signed in to change notification settings 
- Fork 63
Description
Hi:
In order to get compile time checks on the resources and localization files used in my app, I do the following:
1- I create a standalone library called Resources.
2- I use SwiftGen to populate that library with a binary representation of the resources of the app App1.
3- At this point I use Resources as a dependency of other libraries to safely retrieve resources or localized strings.
The folder structure + dependency graph is as follows:
- App1
  * Depends on: //OtherLibraries/OtherLibrary1
  |
  |- Resources
- OtherLibraries
  |
  |- OtherLibrary1
     * Depends on: //App1/Resources
The problem comes when adding a second app to the repository:
- App1
  * Depends on: //OtherLibraries/OtherLibrary1
  |
  |- Resources
- App2
  * Depends on: //OtherLibraries/OtherLibrary1 <-- Here the Resources library that is being used is the one under App1, and this is wrong: it should be the one under App2
  |
  |- Resources
- OtherLibraries
  |
  |- OtherLibrary1
     * Depends on: //App1/Resources
The way this is done in Xcode is by using implicit dependencies inside the Xcode projects that get resolved when that project is inside a workspace (yonaskolb/XcodeGen#224 (comment)).
Is there any way to work around this problem in Buck? For example:
- By somehow inject the location of the Resourcesdependency toOtherLibrary1?
- By not fully specifying the location of the Resourceslibrary inOtherLibrary1, and lettingApp1andApp2rules control it?
- By having a unique Resourceslibrary that depends on agenrulein charge of generating the code from the resources? But, in this case, how to tell thegenrulewhich app resources to use during code generation?
- Any other completely different way that enables compile time safety on resources and lozalization files?
Thanks!
PD: I tried joining the slack channel in order to post this question, but I couldn't because it's limited to employees of specific companies, so I decided to open this issue.