Flutter Intl - multi module translations with synthetic-package enabled - flutter

I have app that has 3 modules - Admin/Guest/Common
I'd like to have arb translations in every module separately.
I managed to do this with some help from answers here, but if admin is my main module, and I'm importing common in pubspec like that:
dependencies:
common:
path: ../common/
Translations from common are not automatically created using syntethic-package.
I have to run command inside common directory and generate those files and rerun this on every change in arb files.
fvm flutter gen-l10n \
--arb-dir translations \
--template-arb-file common_en.arb \
--output-localization-file common_localizations.dart \
--output-class CommonLocalizations \
--output-dir lib/translations \
--no-synthetic-package
Is there a way to enable Intl library to no use no-synthetic-package in this case?

Related

What are the differences between a #nrwl/js library and a #nrwl/workspace library?

I have created both in a testing environment but am still having trouble to differentiate between the use cases of the two. They both have the same file structure, slightly different tsconfig.json file, #nrwl/js library is stricter by 2 extra props. Otherwise they seem to be the same. On the official site there is no info regarding the differences between the two.
Any help is appreciated.
#nrwl/js:library
Use to generate a generic typescript library.
npx nx g #nrwl/js:library --name myLibrary --directory common --buildable # creates libs/common/my-library
#nrwl/workspace:library
Use to generate a UI focused typescript library.
npx nx g #nrwl/workspace:library --name myLibrary --directory common --buildable # creates libs/common/my-library
Differences
#nrwl/workspace:library has a .babelrc file that is not present in #nrwl/js:library
#nrwl/workspace:library has a jest.config.ts that supports .tsx files while #nrwl/js:library only supports .ts files
The tsconfig files are different
How I found the differences
I created a library using each generator
npx nx g #nrwl/js:library --name library --directory common/nrwljs --buildable
npx nx g #nrwl/workspace:library --name library --directory common/nrwlworkspace --buildable
Then I compared the files of each
diff -rq libs/common/nrwljs/library libs/common/nrwlworkspace/
Only in libs/common/nrwlworkspace/library: .babelrc
Files libs/common/nrwljs/library/README.md and libs/common/nrwlworkspace/library/README.md differ
Files libs/common/nrwljs/library/jest.config.ts and libs/common/nrwlworkspace/library/jest.config.ts differ
Files libs/common/nrwljs/library/package.json and libs/common/nrwlworkspace/library/package.json differ
Files libs/common/nrwljs/library/project.json and libs/common/nrwlworkspace/library/project.json differ
Files libs/common/nrwljs/library/src/index.ts and libs/common/nrwlworkspace/library/src/index.ts differ
Only in libs/common/nrwljs/library/src/lib: common-nrwljs-library.spec.ts
Only in libs/common/nrwljs/library/src/lib: common-nrwljs-library.ts
Only in libs/common/nrwlworkspace/library/src/lib: common-nrwlworkspace-library.spec.ts
Only in libs/common/nrwlworkspace/library/src/lib: common-nrwlworkspace-library.ts
Files libs/common/nrwljs/library/tsconfig.json and libs/common/nrwlworkspace/library/tsconfig.json differ
Files libs/common/nrwljs/library/tsconfig.lib.json and libs/common/nrwlworkspace/library/tsconfig.lib.json differ
Files libs/common/nrwljs/library/tsconfig.spec.json and libs/common/nrwlworkspace/library/tsconfig.spec.json differ
It's about the options you can use for each generator. Here are the documentation of the generators:
https://nx.dev/packages/workspace/generators/library
https://nx.dev/packages/angular/generators/library
Angular generator has some specific options, eg to include routing or lazy behaviours.

How to add Room,Lifecycle,Paging libraries in Android.mk ( AOSP build)

I created an application with Room,Lifecycle,Paging libraries in android studio,its working well.
Then I tried to build the same application in AOSP,But I can't include Room,Lifecycle,Paging libraries.
I found all these libraries in frameworks/support/ .
But i don't have any idea about how to add these libraries.
Any clues on how to do it?
Add the following lines in your Android.mk file
LOCAL_STATIC_ANDROID_LIBRARIES += \
android-arch-room-runtime \
android-arch-paging-runtime \

aggregate several software modules into one package

Is it possible to aggregate several software modules (each having its own bitbake recipe) into one single package? (eg: a package that groups openssl+libnss+curl)
How should I write the recipe? May the PACKAGES keyword help?
I looked at packagegroup, that does not do this.
EDIT: My purpose is to create custom packages for a minimal embedded OS, not the regular rpm or deb, but squashfs based packages.
It "could" look like this my_package.bb
DESCRIPTION = "My package"
inherit packagegroup
DEPENDS_${PN}= "\
openssl \
libnss \
curl \
"
Then just include the package where you need it, e.g., my_super_package.bb
DESCRIPTION = "My super package"
inherit packagegroup
DEPENDS_${PN} = "my_package"
Please have a look at this post: https://lists.yoctoproject.org/pipermail/yocto/2014-July/020412.html

How to determine dependencies of recipes in yocto?

I want to add gedit to the the image. But i am not able to find the dependencies of gedit package. How to find the dependencies (DEPENDS) in yocto.
You can use the following command which opens up a Dependency explorer that displays dependencies on the packages:
bitbake -g recipe-name -u depexp
or bitbake -g gedit -u depexp, in your case.
On pyro and later use:
bitbake -g recipe-name -u taskexp
Note: this command needs python-gtk2 installed.
You can also use Toaster, which is a web UI that collects information about what you build, including dependencies. This video shows the dependency information provided:
https://www.youtube.com/watch?v=x-6dx4huNnw
Details on how to set up and use Toaster at
https://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html
The list of packages installed in your image is stored in the manifest file (besides of build history which is already mentioned).
Content of the manifest file looks like:
alsa-conf cortexa7hf-neon-vfpv4 1.1.2-r0.1
alsa-conf-base cortexa7hf-neon-vfpv4 1.1.2-r0.1
alsa-lib cortexa7hf-neon-vfpv4 1.1.2-r0.1
alsa-states cortexa7hf-neon-vfpv4 0.2.0-r5.1
alsa-utils-alsactl cortexa7hf-neon-vfpv4 1.1.2-r0.5
alsa-utils-alsamixer cortexa7hf-neon-vfpv4 1.1.2-r0.5
...
The list consists of the package name, architecture and a version.
That manifest is located in the deploy directory (i.e. deploy/images/${MACHINE}/). Here as an example of the directory listing (there are target images and the manifest file)
example-image-genericx86.ext3
example-image-genericx86.manifest
example-image-genericx86.tar.bz2

Eclipse PDE headless builds modifies source dirs and MANIFEST.MF

The problem
From a number of OSGi bundles, I am creating a p2 update site using the PDE headless feature build. I don't want to copy the entire source tree (if it can be avoided) so I point the buildDirectory property to the location of my sources.
The general problem I encounter is that the PDE build sprinkles build artifacts all over the source directory (and not like all other decent build tools where the build artifacts are stored to a separate location like e.g. Maven's target folder). I can live with this but more annoying is that the PDE build modifies the MANIFEST.MF file of each compiled bundle.
The only real change to the MANIFEST.MF file is that
Bundle-Version: 1.0.0.qualifier
is rewritten to
Bundle-Version: 1.0.0.<yyyyMMddhhmm>
Apart from that, the entire file is reformatted. Of course it is correct to rewrite the file to what should end up in the assembled jars but the modified manifest should IMHO not overwrite the source manifest.
A possible solution?
Does anybody know if there is a way to tell PDE headless build to send all build artifacts to a location separate from the source files?
The nitty gritty details...
Please find below the details about my build.
How I call PDE headless
This is the command I use to call PDE headless build:
java \
-jar \
<prefix>/eclipse/3.8.1/SDK/plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar \
-application \
org.eclipse.ant.core.antRunner \
-buildfile \
<prefix>/eclipse/3.8.1/SDK/plugins/org.eclipse.pde.build_3.8.1.v20120725-202643/scripts/build.xml \
-data \
<prefix>/target/pde_workspace \
-Dbuilder=<prefix>/eclipse/3.8.1/SDK/plugins/org.eclipse.pde.build_3.8.1.v20120725-202643/templates/headless-build \
-DtopLevelElementId=org.example.myproject.feature \
-DtopLevelElementType=feature \
-DbuildDirectory=<prefix>/source \
-DbaseLocation=<prefix>/targetPlatform \
-DjavacSource=1.7 \
-DjavacTarget=1.7 \
-DcompilerArg=-g \
-DbuildLabel=output \
-DarchivePrefix=org.example.myproject \
-DbuildId=org.example.myproject.feature \
-DarchivesFormat=*,*,* - folder \
-Dp2.gathering=true \
-Dp2.build.repo=<prefix>/target/update-site \
-DskipMirroring=true \
-DcollectingFolder=<prefix>/target/tmp
My hope was that adding -DcollectingFolder would redirect all build artifacts to this folder, but it is left empty.
PDE headless documentation
The documentation for PDE headless builds is comprehensive yet somewhat imprecise. For example, for one of its many options it says:
buildType: Type of build, normally something like I, N, M, etc.
The documentation I have been able to find is this:
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Freference%2Fpde_builder_config.htm
Does anyone know of other documentation of the PDE headless builds?
You want to set the properties buildTempFolder and feature.temp.folder. I don't believe that these properties are documented anywhere.
If you are familiar with ant, the way to discover this would be to look at the build.xml file that gets generated for a plugin. In the <init> target, if buildTempFolder is set, then the build will end up setting something like
build.result.folder=${buildTempFolder}/plugins/org.example.plugin_1.2.3.201411110853`
If buildTempFolder is not set, then the default value is ${basedir}, which is the root folder of the plugin.
This build.result.folder will be the destination for most of the compiled .class files (see the <#dot> target), and the manifest will be copied there before it is modified (see the <publish.bin.parts> target. If you use customBuildCallbacks, then everything will be staged here before calling your custom callbacks.
The feature.temp.folder is similar to the buildTempFolder but affects features instead of plugins.