I want to remove 'inherit' using .bbappend.
For example,
In component.bb :
inherit something
In component.bbappend:
"remove_inherit" something
How I can remove inherit configuration using bbappend?
Is it possible?
As far as i know, this is not possible. All you can do in .bbappend is to override variables, defined in the original .bb recipe. So graceful solution would be exactly this - look carefully through original .bb recipe, understand how it works and tinker it in your .bbappend by overriding variables and functions, that originally were defined in .bb-file and .bbclass-files it was inherited from.
Optionally there is a bruteforce solution - just copy-paste original .bb-recipe (and all it's accompanying resources) into your layer and do with this whatever you want))
Related
I have stumbled upon this pen.
In it's code there are fragments using var(--tx, 0)
Then variable --tx is referenced and set in JS via
document.documentElement.style.setProperty('--tx', 'valueForProperty');
I searched google, mdn etc. and found out css3 variables. But what I understood, about them, is that one declares variables in :root pseudo element then use them with var keyword (mdn).
I didn't find information about second variable to var. I guess var(name, value) initializes variable in place, yet I couldn't replicate this in my pen.
The original author uses SCSS preprocesor, it might be the catch, but it declares variables with $ sign.
So I ask if somebody can explain, what's going on in this pen in regards to var statements.
We have a single MACHINE which we use to build two target images; foo-image and foobar-image. Both images consume the same version of a package, but we would like to add a change to the do_install task based on which image is built. So that the recipe file for the package looks something like this:
do_install (){
//Some work
}
do_install_append_foobar-image(){
//Some foobar work
}
Eventually when we do the build for the two images:
MACHINE=custom bitbake foo-image
MACHINE=custom bitbake foobar-image
The image for foobar will contain the installed package that has done the work in the appends task, but the image for foo will not.
Is there any way to do what I have outlined or what would be an alternative?
No, you can't perform different tasks in a recipe based on which image is being built. There might be a possibility of checking the image name in the do_install though I'm highly unsure.
What I'd do is the following:
In the recipe, add a 2nd package which includes the additional files (if that's what you want to do).
Have your 2nd image recipe include this 2nd package.
Another possibility, depending on if you can detect which image you have built, is to add a post_install-script, that does the modification for you. A third, maybe less good option would be to do changes in a ROOTFS_POSTPROCESS_COMMAND.
Which solution you choose, will depend on what kind of customization you want to.
After some deliberation we were probably thinking about this backwards. We probably want to inject separation at the MACHINE level. Since both will be separate products in the end this makes the most sense. Doing it this way will allow us to introduce changes to packages for that specific product.
Our build lines will become:
MACHINE=custom1 bitbake foo-image
MACHINE=custom2 bitbake foobar-image
And our install task for the package can be:
do_install (){
//Some work
}
do_install_append_custom2(){
//Some more work
}
I am familiar with bindings with curly braces, like {{variable}}, from Polymer 0.5.
However, in examples and code snippets for the release version of Polymer, I've begun to notice bindings with square brackets, such as [[variable]], as well.
Does {{variable}} mean something different now, or is it the same and [[variable]] is just an addition? What is the difference between binding to [[variable]] and {{variable}} in Polymer?
Just as you've noticed, there are now two different syntaxes for data-binding, which have different purposes:
{{variable}} indicates that you would like Polymer to automatically detect whether or not the binding should be one-way or two-way.
[[variable]] indicates that you want the binding to one-way only.
Why the change?
Polymer 1.x differs from older versions is that bindings are now one-way by default, much unlike 0.5, where they were always two-way.
In other words, if you write
<my-element some-property="{{myVariable}}"></my-element>
then by default, when
myVariable is changed, Polymer updates the binding, and thus updates my-element's someProperty.
someProperty is changed, Polymer does not update the binding to myVariable.
This is always the case unless you set notify:true on the property inside my-element:
Polymer({
is: 'my-element',
properties: {
someProperty: {
notify: true,
...
With notify: true, the binding is now two-way, so when
myVariable is changed, Polymer updates the binding to someProperty.
someProperty is changed, Polymer also updates the binding to myVariable.
This behaviour (when using notify: true) used to be default in 0.5; now you must ask for it explicitly.
When to use [[variable]]
There's no technical reason why you must use [[variable]], because Polymer will automatically detect whether bindings are one or two-way with {{variable}}. So why would you use it?
Let's say you're working in a large project, and you know that based on the way that data flows in a particular page/element, a certain property should never be changed by the element it is being bound to, for example in the case of an element which functionally serves a purpose as a label:
<display-data source-data="{{data}}"></display-data>
...
<data-editor source-data="{{data}}"></data-editor>
Everything looks good! The data property is bound to both the display-data element and data-editor elements, and will be automatically shared between them. (In this example, assume display-data's sole purpose is to preview the data that it is bound to.)
One day, you or someone else is editing display-data, and you forget about the situation in which it is being used in above. For an entirely different use-case, you or the other developer would like display-data to also format or otherwise modify the data it is given and push it back towards any other elements that may be bound to it. You/they edit display-data as such:
Add notify: true to sourceData, to allow two-way data-binding.
Add code into display-data which modifies the sourceData property.
This works great for all the pages that needed this functionality. But on the page mentioned before, this was not intended and ends up garbling the data that data-editor sees!
This problem would have been avoided had:
The dev team communicated better and had been more considerate of where elements are being used,
and/or [[data]] was used instead of {{data}} in the page/element in question.
With
<display-data source-data="[[data]]"></display-data>
...
<data-editor source-data="{{data}}"></data-editor>
data-editor can change data, but display-data will only ever be able to read data, and won't be able to change its value when it changes the value of its sourceData property, even when notify: true is set on sourceData.
Therefore, it could potentially be a good idea to:
Use [[variable]] whenever you need to bind to variable. This way, you enforce the direction through which data should flow in your element/page/application.
Use {{variable}} whenever you know that the binding must be two-way.
According to the documentation,
To make your code more easier to read, you may want to use the [[property]] form by default, and only use {{property}} for two-way bindings.
This being said, however, it ultimately comes down to a matter of choice. If you want to forego the use of [[variable]], no one is stopping you and you will not start any fires.
I don’t understand the difference between let mapleader="," and let g:mapleader=",". I know that g: means that it’s a global variable, but I don’t clearly understand the difference. Which one should I use in my .vimrc file?
If the aforementioned statements are both located outside of function
definitions, they have the identical effect of setting a global variable. However, if the first statement, without the g: prefix, is used in
a function body, it defines a variable local to that function.
See :help internal-variables and especially :helpg In a function:.
Hence, outside function definitions one can access the global map-leader
variable simply as mapleader.
let mapleader=","
as stated in the doc.
Why would you want to use g:mapleader? g: is mostly used in plugins to let global variables in order to expose settings to other plugins or for you to play with in your .vimrc.
How can I tell the Closure Compiler not to rename an inner function? E.g., given this code:
function aMeaninglessName() {
function someMeaningfulName() {
}
return someMeaningfulName;
}
...I'm fine with Closure renaming the outer function (I actively want it to, to save space), but I want the function name someMeaningfulName left alone (so that the name shown in call stacks for it is "someMeaningfulName", not "a" or whatever). This despite the fact that the code calling it will be doing so via the reference returned by the factory function, not by the name in the code. E.g., this is purely for debugging support.
Note that I want the function to have that actual name, not be anonymous and assigned to some property using that name, so for instance this is not a duplicate of this other question.
This somewhat obscure use case doesn't seem to be covered by either the externs or exports functionality. (I was kind of hoping there'd be some annotation I could throw at it.) But I'm no Closure Compiler guru, I'm hoping some of you are. Naturally, if there's just no way to do that, that's an acceptable answer.
(The use case is a library that creates functions in response to calls into it. I want to provide a version of the library that's been pre-compressed by Closure with SIMPLE_OPTIMIZATIONS, but if someone is using that copy of the library with their own uncompressed code and single-stepping into the function in a debugger [or other similar operations], I want them to see the meaningful name. I could get around it with eval, or manually edit the compressed result [in fact, the context is sufficiently unique I could throw a sed script at it], but that's awkward and frankly takes us into "not worth bothering" territory, hence looking for a simple, low-maintenance way.)
There is no simple way to do this. You would have to create a custom subclass of the CodingConvention class to indicate that your methods are "local" externs (support for this was added to handle the Prototype library). It is possible that InlineVariables, InlineFunctions, or RemoveUsedVariables will still try to remove the name and would also need to be fixed up.
Another approach is to use the source maps to remap the stack traces to the original source.
read the following section
https://developers.google.com/closure/compiler/docs/api-tutorial3#export
Two options basically, use object['functionName'] = obj.functionName or the better way
use exportSymbol and exportProperty both on the goog object, here is the docs link for that
http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.html
-- edit
ah, i see now, my first answer is not so great for you. The compiler has some interesting flags, the one which might interest you is DEBUG, which you can pass variables into the compiler which will allow you to drop some debugging annotations in via logging or just a string which does nothing since you are using simple mode.
so if you are using closure you can debug against a development version which is just a page built with dependiencies resolved. we also the drop the following in our code
if(DEBUG){
logger.info('pack.age.info.prototype.func');
}