What is the 'modules' part of the manifest.json file? The Minecraft wiki does not explain what it does.
Also, I have been told to write my question here on meta stack exchange.
This section describes the modules that comprise the pack. Each entry here defines one of the kinds of contents of the pack.
From https://minecraft.fandom.com/wiki/Bedrock_Edition_add-on_documentation
It defines the type of pack you make, so the game knows how to treat it. For example:
"type": "resources"
will let the game know it's a resourcepack.
...and define the "type" to be "resources". This makes your pack a Resource Pack, also called a Client pack or a Texture pack. It changes things in-game visually.
it is very much like a Resource pack manifest, except the "type" is "data"(for a Data Pack/Behavior Pack)
(From https://sites.google.com/view/mcbe-add-on-tutorial/-/manifest-function)
Can be any of the following: resources, data, client_data, interface, world_template
Hope it answers your question.
Related
I've googled around a bit but I've not found anything really satisfactory. There are a lot of tutorials on how to use them, but I'm struggling to understand which one best fits a particular project.
It's not very clear to me, for each of them, what should I use for. As far as I understood (and that might not be right), all of them overlap in some features, such as defining environment or CMake variables.
What I've generally understood is that CMakePresets and CMakeSettings are Microsoft tools (maybe tool is not the right word, but I couldn't come up with a better one) for integration of a CMake project in MS IDE (VS and VSCode). How they cope with CMakeLists and what are the scope of each one?
Every project needs to have a CMakeLists.txt file that configures the CMake project. You can learn more step-by-step by following the official CMake tutorial. Here's a tutorial on CMakeLists.txt files by CLion.
CmakePresets.json is an optional CMake feature. It is not (as you guessed) a Microsoft-specific tool. It is a tool to allow writing up presets for configuration, build, test, and packaging settings that are commonly used together. That's what it's useful for. Ex. filling in option() variables (that are defined in the project's CMakeLists.txt file). Presets are basically a tool to not have to write many commonly-used-together commandline arguments for common user scenarios and instead have a shortcut/alias for them.
CMakeSettings.json is specific to Visual Studio. You can use it when building projects specifically with Visual Studio. It has some similar capabilities as CMakePresets.json files, but is much more oriented to work with Visual Studio IDE configuration.
Here's an analogy for what presets are and when they're useful: Imagine a project is like a sandwich shop where you pick what ingredients you want in the sandwich (what options you want to choose when configuring the project build). Lets say one sandwich shop has (among many other ingredients), bacon, lettuce, tomato, and cucumber, which are the ingredients you like to have in your sandwich. The list of all the possible ingredients to choose from is the CMakeLists.txt file. The shop notices that many people like to order sandwiches with bacon, lettuce, and tomato together, so they make a preset: "B.L.T.". So now, you can tell them what you want faster: Instead of bacon, lettuce, tomato, and cucumber, you can say: "I want a B.L.T. with onion". Now imagine a different shop with many more ingredients, and you often ordering the same thing with many more ingredients. Can you see how that would be useful? Now- not all customers will commonly want the same thing, and the "official" presets are determined by the shop owner (the project maintainers commit a CMakePresets.json file to their project repo), but you might want to have some custom presets. That's what the CMakeUserPresets.json file is for (never committed to project repo. In .gitignore).
So how do you choose what settings to put in the CMakeLists.txt versus a CMakePresets.json if you choose to create one? If you are 100% certain that one specific value for something (a CMake variable, an environment variable, etc.) will always be the desired value to be used and nobody will want anything different, then hardcode it in the CMakeLists.txt. Otherwise, use the appropriate mechanism (Ex. option() or if(DEFINED ...)) to define the setting with an overridable default value in the CMakeLists.txt.
I just upgraded to the newest version of Pharo Smalltalk. Before doing so, I "File-outed" a package from my old version called My-Pharo - a package I use for various configurations and customizations of Pharo itself, most notably a class to put back "Workspace" in the main menu. I then "File-ined/Installed" the file into my new version.
When I checked the SystemBrowser, I had correctly gotten the My-Pharo package, but I'd also picked up a package called My-Pharo-Manifest... I see My-Pharo-Manifest actually is part of my File-Out, and seems to contain the package-comment for My-Pharo .
What is this manifest, what is it's purpose, and how should it be used? Is there something I can/should do to "merge" the manifest (ie. the comment) back into the My-Pharo class? Should I move the content of My-Pharo-Manifest somewhere else? ...Or is my best bet to simply delete the Manifest-package, and re-write the package-comment for My-Pharo?
I'm not a seasoned Pharo developer, I use it just time to time. I'll try to answer your question from the source code. For more detailed answer you would have to get it from the ones that are actually do the development of Pharo.
What is manifest?
Manifest contains package metadata.
what is it's purpose?
The purpose is to make life easier for the SmallLint (Smalltalk Code Critics). It is there for its speedup, because without the manifest the SmallLint would have to check the rule results all the time. Package metadata helps in managing false positives and/or TODOs.
packages: If you check for the where is the #hasPackageNamed: used, you will find out that it is at SmallLintManifestChecker>>manifestBuilderOfPackage:.
methods: if you search for #hasManifestFor: SmallLintManifestChecker>>manifestBuilderOfMethod:
Is there something I can/should do to "merge" the manifest (ie. the
comment) back into the My-Pharo class? Should I move the content of
My-Pharo-Manifest somewhere else?
I would just leave it be. It helps the SmallLint to do its job.
I will keep it short. I have been handed a yocto repository and asked to audit it for the licences used by the build. My end goal is to:
List all the licenses used by the distro (i.e. licenses used by all the tools and utilities built with distro)
Get a copy of the license file
Get the URL on the internet, where that licence text can be found. (if someone else wants to compare it with what I have provided them)
Being a lazy "software engineer" I am, I want to avoid doing this task and just parse all the .bb files to extract all that information.
I have seen some recipes, which include headers, which in turn have the license information. It'd be nice to be able to follow the trail.
This project on GitHub looks promising. But might not get me exactly what I need.
I also have the entire source code and the license file text distributed with the source code. I should be able to write a simple script to achieve this, but the text in some licenses don't contain the type of license itself.
Any pointers will be greatly appreciated.
First of all, you probably want licenses used in your image, not distro, as you can build all kinds of recipes within any distro, so what matters is only what you ship, which is your image. The way to find out licenses used by software in an image is already described here, but your question differentiates a bit in that you also want full license texts. That's also easy, it's all there in per-package directories in build/tmp/deploy/licenses.
As for your third subquestion, it's not that easy because even something standard like GPLv2 has little variations from project to project, some have exceptions, some have "(c) $YEARS" written in different way, so what the Openembedded build system gives you is actually more reliable as it's extracted from the source. What is possible is to provide the source code itself (via archiver class) along with license information, anyone really curious could cross-check sources and licenses that way.
You should be able to address 1) and 2) via https://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle .
How can one programmatically determine which type libraries (GUID and version) a given native, VB6-generated DLL/OCX depends on?
For background: The VB6 IDE chokes when opening a project where one of the referenced type libraries can't load one of its dependencies, but it's not so helpful as to say which dependency can't be met--or even which reference has the dependency that can't be met. This is a common occurrence out my company, so I'm trying to supplement the VB6 IDE's poor troubleshooting information.
Relevant details/attempts:
I do have the VB source code. That tells me the GUIDs and versions as of a particular revision in the repo, but when analyzing a DLL/OCX/TLB file I don't know which version of the repo (if any--could be from a branch or might never have been committed to a branch) a given DLL/OCX corresponds to.
I've tried using tlbinf32.dll, but it doesn't appear to be able to list imports.
I don't know much about PE, but I popped open one of the DLLs in a PE viewer and it only shows MSVBVM60.dll in the imports section. This appears to be a special quirk of VB6-produced type libraries: they link only to MSVBVM60 but have some sort of delay-loading mechanism for the rest of the dependencies.
Even most of the existing tools I've tried don't give the information--e.g., depends.exe only finds MSVBVM60.dll.
However: OLEView, a utility that used to ship with Visual Studio, somehow produces an IDL file, which includes the importlib directives. Given that VB doesn't use IDL files, it's clearly generating the information somehow. So it's possible--I just have no idea how.
Really, if OLEView didn't do it I'd have given it up by now as impossible. Any thoughts on how to accomplish this?
It turns out that I was conflating basic DLL functionality and COM. (Not all DLLs are COM DLLs.)
For basic DLLs, the Portable Executable format includes a section describing its imports. The Optional Header's directory 1 is about the DLL's imports. Its structure is given by IMAGE_IMPORT_DESCRIPTOR. This is a starting point for learning about that.
COM DLLs don't seem to have an equivalent as such, but you can discover which other COM components its public interface needs: for each exposed interface, list out the types of their properties and their method arguments, and then use the Registry to look up where those types come from. tlbinf32.dll provides some of the basic functionality for listing members, etc. Here's and intro to that.
I'm new to Doxygen and I'm trying to document an API I am planning to open source. I'd really like to build two sets of documentation, one for end users of the API and one for those who intend to modify it. Is there a way to tag Doxygen comment blocks in a way such that I can generate "user" and "dev" documentation trees? Is there a better solution to my problem? Thanks!
Depending on how your code is structured, you might be able to get away with using two Doxygen config files each including separate source files. The "user" config file would only list the source files containing the public interface to the API, while the "dev" config file would list all source files for the whole project.
This does mean that all your interfaces (e.g. abstract base classes) will need to be documented with the user in mind, but that is usually not a problem as by definition there is unlikely to be any implementation details in an abstract base class.
All your "dev" documentation then sits in the actual classes implementing the interfaces, which are never seen by the API and can be safely omitted by the "user" Doxygen config file.
Of course if your code isn't structured this way it's not going to work, so the only solution I can think of is to fill your comments with a bunch of conditional statements.
In addition to what Malvineous already said, there is the \internal doxygen command.
\internal lets you hide or show part of the documentation by changing INTERNAL_DOCS in the Doxyfile
More information here: http://www.doxygen.nl/manual/commands.html#cmdinternal