minimap2 0.2.24.3 → 0.2.24.6

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: bd42b0827b439d629ee498b2030da81f674f3682a818fafcb0987093bdb49e62
-  data.tar.gz: fad5d4e9df7969c828afbdb1cb1a881b23aef2d0d0b61b124f1f8faa8cc3182a
+  metadata.gz: 5a1518fb8048d902865ee6771fedc9cb9b42693c984ec6616c2d1407597a9f26
+  data.tar.gz: 83501abbd0cedb037edb96c6a630b7c93adff87597950ef03359be41dad0710a
 SHA512:
-  metadata.gz: 7866ba8829f4e8840ce752ae86e5c3fb1b4697e6ad538cbe80c09d93238f9a4cf59c22e52f23d3349eecefcba50bc1d610968c81db2ae0def98984dd83fecc8a
-  data.tar.gz: 3609844781d7d9675175a791e2b20010d95e183920d891d0eceb924c6c408bfad7b2240659f1c3d07ce8eec6f2600830f23415333e6ca630c4df0a4b8ba39f3f
+  metadata.gz: d62d29fd4f5f8254f7fdaa9943cb1141a1fb2b832c33b30568fe659c6b4299a4827f596806c0d38368af53c63a48f1e1dcb2fe9562be7534fa3b1697a8b6b3de
+  data.tar.gz: 86e8179090acf840d615b3172fd1aa92e39c3b106c7629d079dfc473bb1a81180a922c13a19e60e41b54c6fda37534c6e61d9107f756bb87410ffa3fd87b93ce

data/ext/minimap2/lib/simde/CONTRIBUTING.md

@@ -0,0 +1,114 @@
+# Contributing to SIMDe
+
+First off, if you're even reading this, thank you!  There is a lot of
+work to do, and any help is appreciated.
+
+If you haven't already, please read the
+[README](https://github.com/nemequ/simde/blob/master/README.md).  The
+[wiki](https://github.com/nemequ/simde/wiki) also has some good
+information, especially the
+[FAQ](https://github.com/nemequ/simde/wiki/FAQ) and a guide on how to
+[implement a new
+function](https://github.com/nemequ/simde/wiki/Implementing-a-New-Function).
+
+For information on developing for architectures you don't have access
+to, please see the [Development
+Environment](https://github.com/nemequ/simde/wiki/Development-Environment)
+page on the wiki.
+
+If you still have questions, or if anything below doesn't make sense
+to you, please feel free to use the [issue
+tracker](https://github.com/nemequ/simde/issues) or the [mailing
+list](https://groups.google.com/forum/#!forum/simde) to ask.  I know
+the SIMDe documentation needs a lot of improvement, and asking
+questions will help us understand what is missing, so please don't be
+shy!
+
+## Building the Tests
+
+SIMDe contains an extensive test suite used for development.  Most
+users will never need to build the suite, but if you're contributing
+code to SIMDe you'll need to build them.
+
+Here is the basic procedure for compiling the tests:
+
+```bash
+mkdir test/build
+cd test/build
+CFLAGS="-march=native" CXXFLAGS="-march=native" cmake ..
+make -j
+./run-tests
+```
+
+Note that `-march=native` may not be the right flag for your compiler.
+That should work for most compilers on x86/x86_64, though MSVC is an
+exception (try `/arch:AVX2` instead of `-march=native`).  On other
+architectures please consult your compiler documentation to find out
+what flags you should use to enable the SIMD extension for your target
+platform.  Here are a few to try:
+
+ * ARM:
+   * `-march=armv8-a+simd` (for ARMv8)
+   * `-march=armv7-a -mfpu=neon` (for ARMv7)
+ * POWER
+   * `-mcpu=native`
+
+If you need a flag not listed above, please let us know so we can add
+it to the list.
+
+## Coding Style
+
+SIMDe uses two spaces for indentation.  Please adjust your editor
+accordingly.
+
+The coding style for preprocessor macros is a bit mixed since I made
+some changes mid-project.  For new code, please indent the
+preprocessor conditions before the hash to the same level as the
+normal code would be, and indent the code inside of preprocessor
+conditions as if the conditions were normal code.  For example:
+
+```c
+int
+foo(void) {
+  #if 1
+    bar();
+  #else
+    baz();
+  #endif
+}
+```
+
+Other than that, please just try to follow the existing style.  We'll
+add new rules here as the need arises.
+
+## Commit Messages
+
+Git commit messages should contain lines no longer than 72 characters.
+The first line should always be a one-line summary of the commit, with
+the relevant component followed by a colon and a space (if
+applicable), then the summary.
+
+If the one-line summary is insufficient to fully describe the changes
+further descriptive paragraphs should be added, separated by blank
+lines.
+
+For example:
+
+```
+sse: add magical code to make everything go fast
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur
+interdum scelerisque risus non ultricies. Vivamus id tristique mauris.
+Mauris et augue vel urna aliquam posuere. Morbi in sem nec ante
+ullamcorper ultrices in quis nibh. In felis velit, semper a mauris sed,
+congue ullamcorper enim. Vestibulum ante ipsum primis in faucibus orci
+luctus et ultrices posuere cubilia Curae; Nulla facilisi. Donec
+scelerisque elit dui, et aliquet magna tincidunt eu.
+
+Curabitur rhoncus lacus ac elit pulvinar, quis posuere ante ultrices.
+Suspendisse at mauris vitae justo pretium tempor et in mauris. Nunc
+facilisis nulla a ante tincidunt, imperdiet rhoncus metus interdum.
+Vivamus sed nunc vel tellus porta consequat. Donec quis porttitor elit,
+et cursus urna. Donec et sapien lorem. In imperdiet magna at aliquet
+hendrerit.
+```

data/ext/minimap2/lib/simde/COPYING

@@ -0,0 +1,20 @@
+Copyright (c) 2017 Evan Nemerson <evan@nemerson.com>
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/ext/minimap2/lib/simde/README.md

@@ -0,0 +1,333 @@
+# SIMD Everywhere
+[![Gitter chat](https://badges.gitter.im/gitterHQ/gitter.png)](https://gitter.im/simd-everywhere/community)
+
+The SIMDe header-only library provides fast, portable implementations of 
+[SIMD intrinsics](https://en.wikipedia.org/wiki/SIMD) on hardware which
+doesn't natively support them, such as calling [SSE](https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions)
+functions on ARM.  There is no performance penalty if the hardware
+supports the native implementation (*e.g.*, SSE/[AVX](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions)
+runs at full speed on [x86](https://en.wikipedia.org/wiki/X86),
+[NEON](https://en.wikipedia.org/wiki/ARM_architecture#Advanced_SIMD_(Neon)) on [ARM](https://en.wikipedia.org/wiki/ARM_architecture),
+*etc.*).
+
+This makes porting code to other architectures much easier in a few
+key ways:
+
+First, instead of forcing you to rewrite everything for each
+architecture, SIMDe lets you get a port up and running almost
+effortlessly.  You can then start working on switching the most
+performance-critical sections to native intrinsics, improving
+performance gradually.  SIMDe lets (for example) SSE/AVX and NEON code
+exist side-by-side, in the same implementation.
+
+Second, SIMDe makes it easier to write code targeting [ISA](https://en.wikipedia.org/wiki/Instruction_set_architecture)
+extensions you don't have convenient access to.  You can run NEON code on your
+x86 machine *without an emulator*.  Obviously you'll eventually want
+to test on the actual hardware you're targeting, but for most
+development, SIMDe can provide a much easier path.
+
+SIMDe takes a very different approach from most other SIMD abstraction
+layers in that it aims to expose the entire functionality of the
+underlying instruction set.  Instead of limiting functionality to the
+lowest common denominator, SIMDe tries to minimize the amount of
+effort required to port while still allowing you the space to optimize
+as needed.
+
+The current focus is on writing complete portable implementations,
+though a large number of functions already have accelerated
+implementations using one (or more) of the following:
+
+ * SIMD intrinsics from other ISA extensions (e.g., using NEON to
+   implement SSE).
+ * Compiler-specific vector extensions and built-ins such as
+   [`__builtin_shufflevector`](http://clang.llvm.org/docs/LanguageExtensions.html#langext-builtin-shufflevector)
+   and
+   [`__builtin_convertvector`](http://clang.llvm.org/docs/LanguageExtensions.html#langext-builtin-convertvector)
+ * Compiler auto-vectorization hints, using:
+   * [OpenMP 4 SIMD](http://www.openmp.org/)
+   * [Cilk Plus](https://www.cilkplus.org/)
+   * [GCC loop-specific pragmas](https://gcc.gnu.org/onlinedocs/gcc/Loop-Specific-Pragmas.html)
+   * [clang pragma loop hint directives](http://llvm.org/docs/Vectorizers.html#pragma-loop-hint-directives)
+
+For an example of a project using SIMDe, see
+[LZSSE-SIMDe](https://github.com/nemequ/LZSSE-SIMDe).
+
+You can [try SIMDe online](https://simde.netlify.com/godbolt/demo)
+using Compiler Explorer and an amalgamated SIMDe header.
+
+If you have any questions, please feel free to use the
+[issue tracker](https://github.com/nemequ/simde/issues) or the
+[mailing list](https://groups.google.com/forum/#!forum/simde).
+
+## Current Status
+
+There are currently complete implementations of the following instruction
+sets:
+
+ * [MMX](https://en.wikipedia.org/wiki/MMX_(instruction_set))
+ * [SSE](https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions)
+ * [SSE2](https://en.wikipedia.org/wiki/SSE2)
+ * [SSE3](https://en.wikipedia.org/wiki/SSE3)
+ * [SSSE3](https://en.wikipedia.org/wiki/SSSE3)
+ * [SSE4.1](https://en.wikipedia.org/wiki/SSE4#SSE4.1)
+ * [AVX](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions)
+ * [FMA](https://en.wikipedia.org/wiki/FMA_instruction_set)
+
+As well as partial support for many others; see the
+[instruction-set-support](https://github.com/nemequ/simde/issues?q=is%3Aissue+is%3Aopen+label%3Ainstruction-set-support+sort%3Aupdated-desc)
+label in the issue tracker for details on progress.  If you'd like to
+be notified when an instruction set is available you may subscribe to
+the relevant issue.
+
+If you have a project you're interested in using with SIMDe but we
+don't yet support all the functions you need, please file an issue
+with a list of what's missing so we know what to prioritize.
+
+The `master` branch is protected so commits never reach it unless
+they have passed extensive CI checks.  Status badges don't really
+make sense since they will always be green, but here are the links:
+
+* [Travis CI](https://travis-ci.org/nemequ/simde)
+* [AppVeyor](https://ci.appveyor.com/project/quixdb/simde)
+* [GitHub Actions](https://github.com/nemequ/simde/actions)
+* [Azure Pipelines](https://dev.azure.com/simd-everywhere/SIMDe/_build)
+* [Drone CI](https://cloud.drone.io/nemequ/simde)
+
+## Contributing
+
+First off, if you're reading this: thank you! Even considering
+contributing to SIMDe is very much appreciated!
+
+SIMDe is a fairly large undertaking; there are a *lot* of functions to
+get through and a lot of opportunities for optimization on different
+platforms, so we're very happy for any help you can provide.
+
+Programmers of all skill levels are welcome, there are lots of tasks
+which are pretty straightforward and don't require any special
+expertise.
+
+If you're not sure how you'd like to contribute, please consider taking
+a look at [the issue tracker](https://github.com/nemequ/simde/issues).
+There is a [good first issue](https://github.com/nemequ/simde/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
+tag if you want to ease into a your first contributions, but if you're
+interested in something else please get in touch via the issue tracker;
+we're happy to help you get a handle on whatever you are interested in.
+
+If you're interested in implementing currently unimplemented functions,
+there is [a
+guide](https://github.com/nemequ/simde/wiki/Implementing-a-New-Function)
+explaining how to add new functions and how to quickly and easily get
+a test case in place.  It's a bit rough right now, but if anything is
+unclear please feel free to use the issue tracker to ask about
+anything you're not clear on.
+
+## Usage
+
+First, it is important to note that *you do not need two separate
+versions* (one using SIMDe, the other native).  If the native functions
+are available SIMDe will use them, and compilers easily optimize away
+any overhead from SIMDe; all they have to do is some basic inlining.
+`-O2` should be enough, but we strongly recommend `-O3` (or whatever
+flag instructs your compiler to aggressizely optimize) since many of
+the portable fallbacks are substantially faster with aggressive
+auto-vectorization that isn't enabled at lower optimization levels.
+
+Each instruction set has a separate file; `x86/mmx.h` for MMX,
+`x86/sse.h` for SSE, `x86/sse2.h` for SSE2, and so on.  Just include
+the header for whichever instruction set(s) you want, and SIMDe will
+provide the fastest implementation it can given which extensions
+you've enabled in your compiler (i.e., if you want to use NEON to
+implement SSE, you may need to pass something like `-mfpu=neon`
+or `-march=armv8-a+simd`.  See
+[GCC ARM-Options](https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html)
+for more information).
+
+If you define `SIMDE_ENABLE_NATIVE_ALIASES` before including SIMDe
+you can use the same names as the native functions.  Unfortunately,
+this is somewhat error-prone due to portability issues in the APIs, so
+it's recommended to only do this for testing.  When
+`SIMDE_ENABLE_NATIVE_ALIASES` is undefined only the versions prefixed
+with `simde_` will be available; for example, the MMX `_mm_add_pi8`
+intrinsic becomes `simde_mm_add_pi8`, and `__m64` becomes `simde__m64`.
+
+Since SIMDe is meant to be portable, many functions which assume types
+are of a specific size have been altered to use fixed-width types
+instead.  For example, Intel's APIs use `char` for signed 8-bit
+integers, but `char` on ARM is generally unsigned.  SIMDe uses `int8_t`
+to make the API portable, but that means your code may require some
+minor changes (such as using `int8_t` instead of `char`) to work on
+other platforms.
+
+That said, the changes are usually quite minor.  It's often enough to
+just use search and replace, manual changes are required pretty
+infrequently.
+
+For best performance, in addition to `-O3` (or whatever your compiler's
+equivalent is), you should enable OpenMP 4 SIMD support by defining
+`SIMDE_ENABLE_OPENMP` before including any SIMDe headers, and
+enabling OpenMP support in your compiler.  GCC and ICC both support a
+flag to enable only OpenMP SIMD support instead of full OpenMP (the OpenMP
+SIMD support doesn't require the OpenMP run-time library); for GCC the
+flag is `-fopenmp-simd`, for ICC `-qopenmp-simd`.  SIMDe also supports
+using [Cilk Plus](https://www.cilkplus.org/), [GCC loop-specific
+pragmas](https://gcc.gnu.org/onlinedocs/gcc/Loop-Specific-Pragmas.html),
+or [clang pragma loop hint
+directives](http://llvm.org/docs/Vectorizers.html#pragma-loop-hint-directives),
+though these are not nearly as effective as OpenMP SIMD and depending
+on them will likely result in less efficient code.
+
+## Portability
+
+### Compilers
+
+SIMDe does depend on some C99 features, though the subset supported by
+MSVC also works.  While we do our best to make sure we provide optimized
+implementations where they are supported, SIMDe does contain portable
+fallbacks which are designed to work on any C99 compiler.
+
+Every commit is tested in CI on multiple compilers, platforms, and
+configurations, and our test coverage is extremely extensive.
+Currently tested compilers include:
+
+ * GCC versions back to 4.8
+ * Clang versions back to 7
+ * Microsoft Visual Studio back to 12 (2013)
+ * IBM XL C/C++
+ * Intel C/C++ Compiler (ICC)
+ * PGI C Compiler
+
+I'm generally willing to accept patches to add support for other
+compilers, as long as they're not too disruptive, *especially* if we
+can get CI support going.  We currently use Travis CI, AppVeyor, and
+Microsoft Azure Pipelines, but other CI platforms can be added as
+necessary.
+
+### Hardware
+
+The following architectures are tested in CI for every commit:
+
+ * x86_64
+ * x86
+ * AArch64
+ * ARMv8
+ * ARMv7
+ * PPC64
+ * MIPS
+
+We would love to add more, so patches are extremely welcome!
+
+The tests currently contain some assumptions that they are running on
+a little-endian CPU.  We're working on this, but for now big endian
+CPUs *should* work, but we can't promise.
+
+## Related Projects
+
+ * The "builtins" module in
+   [portable-snippets](https://github.com/nemequ/portable-snippets)
+   does much the same thing, but for compiler-specific intrinsics
+   (think `__builtin_clz` and `_BitScanForward`), **not** SIMD
+   intrinsics.
+ * Intel offers an emulator, the [Intel® Software Development
+   Emulator](https://software.intel.com/en-us/articles/intel-software-development-emulator/)
+   which can be used to develop software which uses Intel intrinsics
+   without having to own hardware which supports them, though it
+   doesn't help for deployment.
+ * [Iris](https://github.com/AlexYaruki/iris) is the only other project
+   I'm aware of which is attempting to create portable implementations
+   like SIMDe.  SIMDe is much further along on the Intel side, but Iris
+   looks to be in better shape on ARM.  C++-only, Apache 2.0 license.
+   AFAICT there are no accelerated fallbacks, nor is there a good way to
+   add them since it relies extensively on templates.
+ * There are a few projects trying to implement one set with another:
+   * [ARM_NEON_2_x86_SSE](https://github.com/intel/ARM_NEON_2_x86_SSE)
+     — implementing NEON using SSE.  Quite extensive, Apache 2.0
+     license.
+   * [sse2neon](https://github.com/jratcliff63367/sse2neon) —
+     implementing SSE using NEON.  This code has already been merged
+     into SIMDe.
+   * [veclib](https://github.com/IvantheDugtrio/veclib) — implementing
+     SSE2 using AltiVec/VMX, using a non-free IBM library called
+     [powerveclib](https://www.ibm.com/developerworks/community/groups/community/powerveclib/)
+   * [SSE-to-NEON](https://github.com/otim/SSE-to-NEON) — implementing
+     SSE with NEON.  Non-free, C++.
+ * [arm-neon-tests](https://github.com/christophe-lyon/arm-neon-tests)
+   contains tests te verify NEON implementations.
+
+If you know of any other related projects, please [let us
+know](https://github.com/nemequ/simde/issues/new)!
+
+## Caveats
+
+Sometime features can't be emulated.  If SIMDe is operating in native
+mode the functions will work as expected, but if there is no native
+support some caveats apply:
+
+ * Many functions require <math.h> and/or <fenv.h>.  SIMDe will still
+   work without those headers, but the results of those functions are
+   undefined.
+ * x86 / x86_64
+   * SSE
+     * `SIMDE_MM_SET_ROUNDING_MODE()` will use `fesetround()`, altering
+       the global rounding mode.
+     * `simde_mm_getcsr` and `simde_mm_setcsr` only implement bits 13
+       and 14 (rounding mode).
+   * AVX
+     * `simde_mm256_test*` do not set the CF/ZF registers as there is
+       no portable way to implement that functionality.
+     * `simde_mm256_zeroall` and `simde_mm256_zeroupper` are not
+       implemented as there is no portable way to implement that
+       functionality.
+
+Additionally, there are some known limitations which apply when using
+native aliases (`SIMDE_ENABLE_NATIVE_ALIASES`):
+
+* On Windows x86 (but not x86_64), some MMX functions and SSE/SSE2
+  functions which use MMX types (__m64) other than for pointers may
+  return incorrect results.
+
+Also, as mentioned earlier, while some APIs make assumptions about
+basic types (*e.g.*, `int` is 32 bits), SIMDe does not, so many types
+have been altered to use portable fixed-width versions such as
+`int32_t`.
+
+If you find any other differences, please file an issue so we can either fix
+it or add it to the list above.
+
+## Benefactors
+
+SIMDe uses resources provided for free by a number of organizations.
+While this shouldn't be taken to imply endorsement of SIMDe, we're
+tremendously grateful for their support:
+
+ * [GitHub](https://github.com/) — hosts our source repository, issue
+   tracker, etc.
+ * [Travis CI](https://travis-ci.org/) — provides CI testing on
+   numerous platforms.
+ * [AppVeyor](https://www.appveyor.com/) — provides CI testing on
+   Windows.
+ * [Drone CI](https://drone.io/) — provides CI testing on ARM 32 bits
+   platform, etc.
+ * [IntegriCloud](https://integricloud.com/) — provides access to a very
+   fast POWER9 server for developing AltiVec/VMX support.
+ * [GCC Compile Farm](https://gcc.gnu.org/wiki/CompileFarm) — provides
+   access to a wide range of machines with different architectures for
+   developing support for various ISA extensions.
+ * [CodeCov.io](https://codecov.io/) — provides code coverage analysis
+   for our test cases.
+
+Without such organizations donating resources, SIMDe wouldn't be nearly
+as useful or usable as it is today.
+
+We would also like to thank anyone who has helped develop the myriad
+of software on which SIMDe relies, including compilers and analysis
+tools.
+
+Finally, a special thank you to
+[anyone who has contributed](https://github.com/nemequ/simde/graphs/contributors)
+to SIMDe, filed bugs, provided suggestions, or helped with SIMDe
+development in any way.
+
+## License
+
+SIMDe is distributed under an MIT-style license; see COPYING for
+details.

data/ext/minimap2/lib/simde/amalgamate.py

@@ -0,0 +1,58 @@
+#!/usr/bin/python3
+
+# amalgamate.py
+# Written by Evan Nemerson <evan@nemerson.com>
+#
+# To the extent possible under law, the author(s) have dedicated all
+# copyright and related and neighboring rights to this software to
+# the public domain worldwide. This software is distributed without
+# any warranty.
+#
+# For details, see <http://creativecommons.org/publicdomain/zero/1.0/>.
+# SPDX-License-Identifier: CC0-1.0
+
+# Quick and dirty script to amalgamate C into a single file.  Includes
+# using angle brackets (#include <foo.h>) will be preserved, but for
+# includes using double quotes (#include "foo.h") the file will be
+# included by this script.
+#
+# If you make any improvements please report them in the SIMDe issue
+# tracker at <https://github.com/nemequ/simde/issues> or directly to
+# the author so they can be merged back into the original version.
+
+import sys, re, os, subprocess
+
+amalgamate_include = re.compile('^\\s*#\\s*include\\s+\\"([^)]+)\\"\\s$')
+already_included = []
+
+def amalgamate(filename, stream):
+  full_path = os.path.realpath(os.path.realpath(filename))
+  srcdir = os.path.dirname(full_path)
+
+  if full_path not in already_included:
+    already_included.insert(-1, full_path)
+    with open(filename) as input_file:
+      stream.write('/* :: Begin ' + os.path.relpath(full_path) + ' :: */\n')
+
+      for source_line in input_file:
+        a9e_inc_m = amalgamate_include.match(source_line)
+        if a9e_inc_m:
+          amalgamate(os.path.join(srcdir, a9e_inc_m.group(1)), stream)
+        else:
+          stream.write(source_line)
+
+      stream.write('/* :: End ' + os.path.relpath(full_path) + ' :: */\n')
+
+if len(sys.argv) != 2:
+  sys.stderr.write("USAGE: " + sys.argv[0] + ' SOURCE_FILE\n\n')
+  sys.stderr.write("This will print a copy of $SOURCE_FILE to stdout, while replacing\n")
+  sys.stderr.write("all '#include AMALGAMATE(file)' lines with copies of file.\n")
+
+  sys.exit(1)
+
+print('/* AUTOMATICALLY GENERATED FILE, DO NOT MODIFY */')
+
+git_id = subprocess.check_output(["git", "rev-parse", "HEAD"]).decode().strip()
+print("/* {:s} */".format(git_id))
+
+amalgamate(sys.argv[1], sys.stdout)

data/ext/minimap2/lib/simde/meson.build

@@ -0,0 +1,33 @@
+project('SIMDe', 'c', 'cpp',
+        default_options: ['c_std=c99'],
+        license: 'MIT',
+        version: '0.5.0')
+
+cc = meson.get_compiler('c')
+cxx = meson.get_compiler('cpp')
+
+subdir('test')
+
+install_headers(
+    [
+		'simde/hedley.h',
+		'simde/check.h',
+		'simde/debug-trap.h',
+		'simde/simde-arch.h',
+		'simde/simde-common.h',
+
+		'simde/x86/avx2.h',
+		'simde/x86/avx512bw.h',
+		'simde/x86/avx512vl.h',
+		'simde/x86/avx512f.h',
+		'simde/x86/fma.h',
+		'simde/x86/mmx.h',
+		'simde/x86/sse.h',
+		'simde/x86/sse2.h',
+		'simde/x86/sse3.h',
+		'simde/x86/sse4.1.h',
+		'simde/x86/sse4.2.h',
+		'simde/x86/ssse3.h',
+		'simde/x86/svml.h',
+    ],
+    subdir: 'simde')

data/ext/minimap2/lib/simde/netlify.toml

@@ -0,0 +1,20 @@
+[build]
+  publish = 'web'
+  command = 'mkdir -p web/amalgamated/x86 && cd simde && for header in x86/*.h; do ../amalgamate.py "$header" > ../web/amalgamated/"$header"; done'
+
+[[headers]]
+  for = "/amalgamated/x86/*.h"
+  [headers.values]
+    Access-Control-Allow-Origin = "*"
+
+[[redirects]]
+  from = "/godbolt/simple"
+  to = "https://godbolt.org/z/-twon_"
+  status = 302
+  force = true
+
+[[redirects]]
+  from = "/godbolt/demo"
+  to = "https://godbolt.org/z/8cAgiy"
+  status = 302
+  force = true