I have started understanding zephyr
Looking into samples/basic/blinky, there is a file sample.yaml
From Documentation:
Bindings are files in YAML format.
.dts files describe the available hardware devices, but don’t tell the
system which pieces of information are useful, or what kind of
configuration output (#define’s) should be generated. Bindings provide
Just to understand the importance, i moved the sample.yaml into our home folder and built, flashed the led blink application and it blinks.
Is it necessary to have yaml file in our application directory and when it is needed?
this information
yaml files in zephyr are used for:
binding information related to devicetree hardware description
configuration of test cases
As you have already found, devicetree binding are documented here.
About zephyr test framework read all the details in the official docs
In particular, sample.yaml files located inside the application project directory define tests cases
to be executed by the sanitycheck tool. Read here for more details.
Related
There is a issue that is present with some very specific aspect of applications I build using a Qt library provided in repositories of the system I'm using; this issue isn't present with the same numerical build of Qt that I built myself on this exact system.
I would like to query all information about build environment of Qt, it's configuration flags, etc., anything that could help me determine the difference between two build of Qt library.
I've learned about config.summary file, that is present in mine qtbase sources, but there isn't a counterpart anywhere in the system for pre-built version (I have, besides headers, installed a sources and debug information for the qt library packages).
I also tried looking for some header files that could specify, for example, what features were enabled at the build time, but could't locate anything like that (mostly because I don't know the name or some example contents of such file so that I could search for it or grep it), so if there is indeed such file, please point me to it.
I think the best reply is to quote this answer from Qt mailing list
Unfortunately it isn't that easy to figure out but the data is
available; you just need to know from where to search it :D
Configure options can be found from (qtbase) build log, from qt5.git
integration. E.g for 5.6.3
here:https://testresults.qt.io/coin/integration/qt/qt5/tasks/1505476672
and for 5.9.5 here:
https://testresults.qt.io/coin/integration/qt/qt5/tasks/1523412986
And SW details here: https://wiki.qt.io/Qt_5.6_Tools_and_Versions &
https://wiki.qt.io/Qt_5.9_Tools_and_Versions
You can find the latest builds at https://testresults.qt.io/coin/?project=qt%2Fqt5
If you look inside the "Build" section you have all the system configurations Qt is built for (column "Target") and for each configuration the parameters (column "Configure Arguments").
I want to get a path to the project directory in Qt and reference the other files of my project relative to it. I know this issue have been already discussed here
Get current working directory in a Qt application
and here
How to get current working directory path of a Qt application?
but the answer is still unknown. In case it's impossible to get such a path then what is the approach of navigation among files of the Qt project.
Based on your comment, you are trying to:
Access some images which are being used in my program. I could of course put them into build target directory, but it becomes uncomfortable to pass my code to others.
The approach to store resource files in the project source directory and rely on such structure at runtime is not a greatest idea. I can't imagine the situation when mixing the concepts of initially decoupled source and build directories could be useful, correct me if I'm wrong.
So, according to your needs:
The most simple and plain way is to use the Qt resource system. The resource files are simply embedded into the executable, so there will be no need to access the file system.
Another way is the automatic deployment of the needed files. This answer describes the way to copy your files to the target directory using qmake.
I want to translate a program; but its language files (.qm) are in a .rcc file.
The program is not mine, so I haven't got any .qrc file.
Before asking this question, I have searched this site about this issue; but I don't attain anything.
Is there any way to extract/decompile it?
You can take my tool RccExtended - it based on the official Qt resource compiler with additional function to decompile binary resources.
Usage example:
cd \Path\To\MyQtResources\
rcc --reverse
Decompiler will unpack all .rcc files in the current directory, generate .qrc files and make.bat file to compile resources back to the binary format.
There isn't a supported way to decompile it as far as I'm aware, but it's a binary file format that can be read and handled. There's a nodejs example of how to read the file and extract PNGs on github: https://github.com/gcochard/png-extractor. It may be possible to extend that method out for the .qm files.
However there's other issues with attempting to add more translations to a Qt application without having the code, depending on the language you're attempting to add, how the developer has exposed the other languages etc.
I am not a CQ guy. I have to use CQ5 for one of my project. I have a CAT and a production environment. I have following doubts-
I want to use author instance of my CAT only. Once I publish the content in CAT it should publish in Production also. Is it possible ?
Once I update the build of AdobeCQ in my production say new build, code changes etc- will my content be lost ?
I read somewhere about Content package in cq5. Can I separate content changes and code changes in one CQ5 environment ?
Thanks in advance.
To answer question 1...
This is not a recommended setup, but a common misconception for someone unfamiliar with AEM/CQ5. The "author" and "publish" instances should be part of the same environment. For example you should have a production author, probably behind your firewall, and production publish to serve pages to the public.
Your CAT environment should have the same thing. You want your testing environment to match as closely as possible to your production environment, including web server and dispatcher setup, to ensure quality.
Consider this. You can use one production publish instance, but it's a single point of failure. It's a general best practice to load balance across at least two. Two is sufficient for most websites. If you do this, you'd want to mimic the architecture in CAT.
To answer question 2...
If your code is written, built, and deployed correctly, it should not delete your content. Just make sure you are never deploying anything to /content (to avoid deleting content) and to /libs and most of /etc to avoid overriding platform functionality. AEM/CQ5 is a very open product, so you can do very bad things. But, if you know what not to do you are safe.
Code deployments should typically be done as part of a CRX Content Package, which brings me to...
To answer question 3...
The way we build and deploy code is to have Maven compile the Java, package everything up in a CRX Package, then deploy to the instance using the Package Manager REST API. Adobe provides a Maven Archetype that will facilitate this.
A CRX Package is a file system representation of your content repository, wrapped in what is effectively an annotated Zip file. Your compiled Java code is included in that file system representation, in a folder (to become node) named "config". That compiled Java is an OSGi bundle, which is an annotated JAR. When CRX Package Manager deploys all those nodes to the system, OSGi accepts the bundle, assuming it's valid. This is why you can do "hot" deployments of live, production AEM/CQ5 instances, with very little risk.
So...
This is a very high level answer to some very big topics. I encourage you to do a lot more research before you set this up. There are many good blog posts and documentation pages out there to help you get this set up according to best practice. Good luck!
Doxygen is a bit slow - it takes about a couple of minutes to process my whole project, so for small incremental changes this is longer than actually building the rest of my code. There are thousands of files without any documentation so I guess it is spending most of its time processing them. Is there any way to get it to skip files without any documentation?
What about getting it to only process changed files?
From Doxygen documentation:
How can I exclude all test directories
from my directory tree?
Simply put an exclude pattern like
this in the configuration file:
EXCLUDE_PATTERNS = /test/
So, you should be using patterns to exclude files. It's been a long time since I've used Doxygen, but i don't remember any option to process only changed files.
I found that turning off the option SEARCH_INCLUDES made a big difference. It was looking through the whole platform SDK and include paths for the compiler which were not documented anyway and would not appear in the generated documentation.
There is a DOT_NUM_THREADS options which may increase the performance on multicore machines. Unfortunately doxygen itself is just single threaded.
Another approach would be to organize your code into modules run for each module a separate doxygen instance and link the resulting tags together: http://www.doxygen.nl/manual/external.html
Doxygen is good at finding connections between files, either changed or not. But Doxygen does not remember informations about unchanged files, so it must process the whole codebase each time.
May be a solution would be to organize the project such that never changed files belong to one module which is excluded from Doxygen scope and whose documentation is already available. Then it would be possible to tell Doxygen to link newly built documentation to this existing module documentation.
Going further, it would also be possible to make Doxygen running module by module, processing only changed modules and a top level documentation which links to all module documentations.
I don't think having Doxygen run on a normal dev cycle is a good idea. Our Doxygen build runs as part of our Continuous Integration server's responsibilities.
That said, there are some benefits of running doxygen every build to catch missing docs.
So I would trim the doxygen config for dev builds removing diagrams, and even stop apple importing it into xcode.