I am trying to understand Yocto Recipes.
Following is one of the line from a Yocto Recipe:
DEPENDS_append_class-target = " grub-efi-native"
What I understood is this recipe depends on package "grub-efi-native", what I am trying to understand is class-target field.
There are two variables which are present in the manual class-target and class-native.
This is the statement from the Yocto Manual.
Inside the recipe, use _class-native and _class-target overrides to specify any functionality specific to the respective native or target case.
Can anyone explain what the above statement means.. Does it mean that it depends on the target binary and not host binary
Bitbake can use the same recipe to build a recipe for either the target, or the native build host. This is enabled by having BBCLASSEXTEND = "native" in the recipe. This will enable you to use -native to refer to a build of the recipe for the native build host.
But sometimes there's a difference in how you want to build that recipe depending on if you're building for the target or the host, this is when _class-target or _class-native can be used.
So in your example the DEPENDS_append_class-target = " grub-efi-native" line means that when building this recipe for the target, DEPENDS will also include grub-efi-native.
Related
I have two frameworks 'GeneralABC' and 'GeneralXYZ'. Both of them have the same interface but different business logic. I define their module_name in podspec as General, so that other projects using my framework only need to define which General framework(GeneralABC or GeneralXYZ) they want to use in their Podfile, without changing their codes. (i.e. in their code file, they can always say import General)
In my example project, i have two targets, each target using different General framework. My Podfile is as follows:
target 'Example_ABC' do
pod 'GeneralABC'
end
target 'Example_XYZ' do
pod 'GeneralXYZ'
end
however when i try to build one of my target in xcode, I have got the following error
message
Multiple commands produce '/MYPATH/General.framework':
1) Target 'GeneralABC' has create directory command with output 'MYPATH/General.framework'
2) Target 'GeneralXYZ' has create directory command with output 'MYPATH/General.framework'
Multiple commands produce '/MYPATH/General.framework':
1)Target 'GeneralABC' has link command with output 'MYPATH/General.framework'
2)Target 'GeneralXYZ' has link command with output 'MYPATH/General.framework'
It can be solved by two approaches:
changing the workspace settings to legacy build system. however I don't think it is a solution in the future.
remove one of the target in the Podfile, and pod update every time we build the target. however, it is not so nice for maintenance and our build process.
is there any solution that i can manipulate my Podfile, so that i can fix the issue?
I appreciate very much of any suggestions.
Thank you for your attention!
I cannot find the exact solution that I want (1 pod file maintain all the targets). However, after some discussions with our teammates. we come up another kind of solution, so that we don't have to worry about the deprecated legacy build system.
solution are as follows:
create 2 podfile (i.e. 1 for target 'Example_ABC' the other for 'Example_XYZ')
create 2 workspace file (i.e. 1 for target 'Example_ABC' the other for 'Example_XYZ')
a mini shell script, that link the Podfile_ABC or Podfile_XYZ, when do the pod install/update/deintegrate
The two projects I'm working on happen to both make use of XCode at some point during building.
One project is based on Reactive Native, in which case I'd need to set the Build Location to Custom with
Products: build/Build/Products
Intermediates: build/Build/Intermediates
in order for the command react-native run-ios to run properly (or else I'd run into CFBundleIdentifier", Does Not Exist error).
Another project is based on Unity and make use of a custom framework injection, in which case I'd need to set the Build Location to Legacy as there is a custom script that uses the value in the target settings.
To my astonishment I discovered that every time I work on the other project I'd need to reset the Build Location value to the right one for the project or else I'll run into errors/problems.
Is there a way to define a project-specific configuration so that I can have different values for the Build Location for different XCode projects?
One solution I can think of is to stick to Legacy: for the project based on react-native simply define the build location as build/Build/Products in the target settings. But the drawback is that react native may just override the value to the default one at each build and rendering this approach not practical (I have yet tested it out though).
So I'm wondering if there is a "standard" way of resolving this annoying problem.
In Xcode, we have to configure many paths in the Build Settings, then we will deal with the $(SRCROOT) and $(PROJECT_DIR) , But what the difference between them, can you show me an example, thx a lot.
Exchangeable in practice, while the documentation makes these subtle theoretical distinctions:
SRCROOT
Directory path. Identifies the directory containing the target’s source files: contains the path to the project file that defines the target.
SOURCE_ROOT is an undocumented alias to SRCROOT
PROJECT_DIR
Identifies the directory containing the project (.xcodeproj)
$(PROJECT_DIR)/build is used as the create the default value for:
Intermediate Build Files Path OBJROOT
Build Products Path SYMROOT
Typically these paths are not set per target, but are set per-project or per-user.
PROJECT_FILE_PATH
Identifies the project itself.
Equivalent to $(PROJECT_DIR)/$(PROJECT_NAME).xcodeproj
Conceptually different (#1 is about the project which defines the target while #2 is about the project independently of any target), they are always pointing to the same location since you are, in essence, always building a target.
References
Xcode 8.3 Build Settings reference
Xcode Build System Guide (Retired 2016-09-29)
SRCROOT & PROJECT_DIR are same macros have same effect.PROJECT_DIR makes more sense when talking about frameworks.
I have an Xcode Project with three targets:
A Mac app to be distributed on the Mac App Store
The same Mac app, but to be distributed as a demo version on my
website
A login helper app that is a target dependency for the first two
targets
The login helper app is copied on build to the target of the current scheme (let's say the first target), which has a build path of
$(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
When I change the scheme to the second target (the demo), I'd like for the build products path of the third target to be the same, except with _Demo attached to it. Basically, the third target's build path should always be the same as the current scheme's target (either target one or two).
Currently, I do it manually before building, but that's tedious.
Is there no way to make the Per-configuration Build Products Path (and the Per-configuration Intermediate Build Files Path, etc) dependent on the current target?
So when I select the first target, no _Demo gets attached to the path, when I select the second target, _Demo does get attached to the path.
Any pointers would be highly appreciated.
Thank you very much,
Matt
As I understand it, you want the login helper’s building to be aware of which “parent target” it’s being built in. Not sure if that’s possible.
What I’d do in this case, is add a separate “Copy” build step into targets 1 and 2. It sounds like copy is currently a part of building target 3, but it works better if it’s part of building targets 1 and 2.
I have a very similar situation with a command-line helper in one of my tools. Here’s the relevant part of my build settings.
I am trying to integrate Twitter in my application. I import two .jar files with different names, but one package has the same name in both files. When I compile, it shoes following error.
Description Resource Path Location Type
D:\CustomClasses\ksoap2-j2me-core-prev-2.1.2.jar(org/kxml2/io/KXmlParser.class): Error!: Duplicate definition for 'org.kxml2.io.KXmlParser' found in: org.kxml2.io.KXmlParser
Assuming the two JARs are third party (not platform libraries), you should consider a more sophisticated compilation and packaging step. But before going down this path, check to see whether the JARs you are importing don't come in different forms -- ones that don't embed their dependencies.
Either way, have a step in your compilation to extract just the parts that you need from each JAR.
If you are not using build scripts but use an IDE for everything, set up a build script just to build your customized dependencies JAR.