Please make any modifications you like to the individual package pages. Especially desirable contributions are:
Elaborating on details of what the package is, where they are sparse;
Mentioning yourself if you are actively working on it or have some expertise that you'd like to share;
Adding labels to the relevant pages if you (for example) know that something includes NEON optimisations or is known to compile on Arm (with either GCC or the Arm Compiler suite);
Sharing instructions, gotchas, recipes, results and anything else that you think could help those who want to evaluate a particular package on Arm.
The Wiki works as follows:
Package Pages (Add new pages and edit existing pages)
Every package has a page in the packages/ directory. Please feel free to add new pages covering packages we don't yet cover (call them "packages/" to put them in the right directory), and similarly feel free to enhance existing pages with any information you have!
Click the 'edit' button at the top of the package page
Edit the markdown in your browser
Click 'save changes' to update the page, or 'cancel' to abandon your changes
Updating the package master list, category lists and summary tables
Modifications to the packages cause the project pipeline to run, which regenerates the summery data at the bottom of this page, the category pages, and the summary Excel Spreadsheet.
Note: when the category lists (including this page) are autogenerated by the Pipeline, only the part within BEGIN/END AUTOGEN comments is affected. This means that you can add Wiki content above or below those sections in the lists (for example, to say something about OpenHPC) and that content will be preserved when the pages are regenerated.
Each package can be categorised, and these lists are auto-generated by a script. See existing pages for how to assign categories to your package. You can use any categories you like - new package lists will be generated automatically. Category names can be capitalised, but the generated category filenames will be all lowercase.
You can attach labels to packages using the format "Label: key=value" - again, look at existing packages for examples of these.
Please use labels as follows:
Please set to:
Upstream - if an open-source project builds from source on Arm with no modifications (apart from tweaking compiler options for performance);
NeedsPatch - if detailed modification steps for the package are available on the package page or patches are required (and please link to those patches!);
Supported - if a commercial package officially supports 64-bit ARMv8.
In the Excel spreadsheet, Upstream and Supported are shown in green, NeedsPatch in amber.
Set to Yes if you have demonstrated that the package compiles with the Arm Compiler (and set BuildMaturity appropriately depending on whether you needed a patch or not). Set to No if you tried and couldn't make it work. Leave this label out if you don't know.
Set to Yes if you have demonstrated that the package compiles with GCC (and set BuildMaturity appropriately depending on whether you needed a patch or not). Set to No if you tried and couldn't make it work. Leave this label out if you don't know.
Set to Yes if there is NEON-specific optimizations in the project. Set to NA if NEON optimisation doesn't make sense for this package. Both are rendered in green in the Excel spreadsheet.
Application homepage and repository
Please provide a link to the application's homepage and source repository, if available, using the format: