To create an SDK with Bitbake/Yocto, the regular way is to call the populate_sdk task on the image recipe, like that:
bitbake -c populate_sdk my-image
For a special purpose, I would like to create a little recipe that will never be used to build an entire image, but only one customized SDK. I would like to explicitly name the components and libraries that I are part of it.
Is that possible? I imagine directly inheriting populate_sdk.bbclass. But then, how can I specify packages that are part of the SDK, if I don't have the IMAGE_INSTALL variable? Can anyone provide a minimal example of an "SDK-only recipe"?
Have a look at the meta-toolchain recipe as this does something similar.
Related
Setting up a full "KMP" / "KMM" project seems like overkill, as only the commonMain/commonTest directories would be filled.
All the other templates seem to be platform-specific.
Is there something like a "pure" Kotlin library template?
It would just be a module with only commonMain and commonTest. You would need at least:
A Gradle module
Kotlin config with multiple targets in that module
Common code folders
Whether you put the app code in the same repo or have the shared code in a separate repo is up to you. I'm not sure how much simpler you can make the config, though.
One issue I think you'll run into is the need for platform-specific code on iOS because there are different interfaces for concurrency than you might want for a Kotlin-friendly (I.E. Android) environment. Same for things like default params.
My-KMP-Library
│ build.gradle.kts
└───src
└───commonMain
└───kotlin
└───mynamespace
What makes it multiplatform are the targets you specify in build.gradle.kts.
I would like a set of rules from my_package.bzl to be accessible to all BUILD files of a workspace without having to load my_package.bzl in the BUILD files. Basically I want the rules in the package to look like native rules. How can I achieve this?
I was thinking maybe there's a line I could add to one of the .bazelrcs or to the WORKSPACE file of the the project.
This can be achieved by adding a prelude_bazel file at //tools/build_rules:prelude_bazel (this must be a package, so tools/build_rules must contain a BUILD file).
This will be loaded and prepended to all BUILD files loaded by Bazel.
However, there are a few things to consider before going this route. It's currently undocumented, and while doing some searching to find any info on this feature, it's unclear if it will remain a part of Bazel.
It may also have performance / scaling problems. If the prelude were to change (or any of its dependencies), every BUILD file would have to be reloaded, and this may take some time depending on the size of the build graph.
The code_build (https://pub.dartlang.org/packages/code_builde) package provides a solution to generate classes and constructors, field and methods for that class.
My ultimate goal is to generate Flutter (https://flutter.io) Widgets based on the json structure given, but I don't know how to do this with the code_build or another package.
So help would be appreciated!
The general way to write something which outputs Dart code is to wrap up the functionality in a Builder and to perform the code generation with build_runner
At a high level you'd write a Builder that:
Has buildExtensions of {".json": [".dart"]}.
Reads in the buildStep.inputId asset and parses the json.
Uses code_builder to build up a String and then write it to the output asset.
Then you'd configure the builder in build.yaml. And either apply it manually to your package, or if you'd like to publish it as a utility it can apply to dependencies.
Your package would have a dev_dependency on build_runner and then you can execute builds with flutter packages run build_runner build.
There are more docs at https://github.com/dart-lang/build/tree/master/docs
You can see an example of a package which does something similar - starts with yaml files and outputs Dart files using code_builder at https://github.com/natebosch/message_builder
There is now an online tool which will generate the Dart classes from a JSON payload if you're only looking to structure your model classes. It won't do it dynamically at runtime, but it's super helpful when you're first building your program.
https://javiercbk.github.io/json_to_dart/
I like the help which is provided by --help-module. Here you can read how to add new libraries and which variables are being set. Because I only occasionally create a framework from scratch I only add libraries once and forget how to add them for the next time.
So, if I want to create a new project I only have to make a quick search with --help-module and the package I want to use. Unfortunately OpenCV is not in this list. So, I am curious if there is a way to add a help for Opencv?
TLTR; I want to add a help for OpenCV. Where I can refresh my mind on how to find opencv and how link against it etc.
I doubt this can be done.
The help module is generated from the RST CMake documentation. You are not supposed to add it there. It should be part of the documentation from the project which provides the module.
I'm building a program that uses Delphi Packages (BPLs) as plugins, but I'd like to use a custom extension to show that the files have a specific purpose instead of just being BPLs. That works well enough until I end up with one package having a dependency on another. Then the compiler automatically creates the binary with the extension BPL built in.
This wouldn't be too hard to fix with a hex editor, but that's sort of an extreme solution. Is there any way I could make the compiler generate the packages with the right dependency names in the first place?
EDIT: The answers so far seem to have not understood the question.
I know exactly how to create the packages with my custom TEP extension instead of a BPL extension. But if I have package1.TEP and package2.TEP, and package2 depends on package1, and then I try to load package2, it gives an error because it can't find "package1.BPL". What I want is to find some simpler way to make package2 look for the correct filename, "package1.TEP," that doesn't involve editing the binary after it's been created. Is there any way to do that?
Use the {$E} directive.
The simplest solution would be to use a post build event to rename your destination file from *.BPL to whatever specific extension you are requiring.
EDIT:
You could write a separate patch program to search for and patch the offending binaries and run it as part of the post build process. If a patch is made to the compiler, then you can remove your step easily.