fix: compiled page fixes

docs/_includes/pyproject.md

@@ -5,6 +5,7 @@ The metadata is specified in a [standards-based][metadata] format:
 ```toml
 [project]
 name = "package"
+version = "0.1.0"
 description = "A great package."
 readme = "README.md"
 license = "BSD-3-Clause"
@@ -51,10 +52,10 @@ or [Whey](https://whey.readthedocs.io/en/latest/configuration.html). Note that
 The license can be done one of two ways.
 
 The modern way is to use the `license` field and an [SPDX identifier
-expression][spdx]. You can specify a list of files globs in `license-files`.
-Currently, `hatchling>=1.26`, `flit-core>=1.11`, `pdm-backend>=2.4`,
-`setuptools>=77`, and `scikit-build-core>=0.12` support this. Only `maturin`,
-`meson-python`, and `flit-core` do not support this yet.
+expression][spdx]. You can specify a list of files globs in `license-files`. You
+need `hatchling>=1.26`, `flit-core>=1.11` (1.12 for complex license statements),
+`pdm-backend>=2.4`, `setuptools>=77`, `meson-python>=0.18`, `maturin>=1.9.2`,
+`poetry-core>=2.2`, or `scikit-build-core>=0.12` to support this.
 
 The classic convention uses one or more [Trove Classifiers][] to specify the
 license. There also was a `license.file` field, required by `meson-python`, but

docs/pages/guides/packaging_compiled.md

@@ -37,11 +37,13 @@ There are also classic setuptools plugins:
 
 {: .important }
 
-If you have a really complex build, the newer native build backends might not
-support your use case yet, but if that's the case, ask - development is driven
-by community needs. The older, more fragile setuptools based plugins are still a
-bit more flexible if you really need that flexibility for a feature not yet
-implemented in the native backends.
+Selecting a backend: If you are using Rust, use maturin. If you are using CUDA,
+use scikit-build-core. If you are using a classic language (C, C++, Fortran),
+then you can use either scikit-build-core or meson-python, depending on whether
+you prefer writing CMake or Meson. Meson is a lot more opinionated; it requires
+you use version control, it requires a README.md and LICENSE file. It requires
+your compiler be properly set up. Etc. While CMake can be as elegant as Meson,
+there are a lot of historical examples of poorly written CMake.
 
 ## pyproject.toml: build-system
 
@@ -120,6 +122,10 @@ install(TARGETS _core DESTINATION ${SKBUILD_PROJECT_NAME})
 <!-- prettier-ignore-end -->
 <!-- [[[end]]] -->
 
+Scikit-build-core will use your `.gitignore` to help it avoid adding ignored
+files to your distributions; it also has a default ignore for common cache
+files, so you can get started without one, but it's recommended.
+
 {% endtab %} {% tab meson Meson-python %}
 
 Example `meson.build` file (using pybind11, so include `pybind11` in
@@ -157,6 +163,11 @@ install_subdir('src/package', install_dir: py.get_install_dir() / 'package', str
 <!-- prettier-ignore-end -->
 <!-- [[[end]]] -->
 
+Meson also requires that `LICENSE` and `README.md` exist, and that your source
+be tracked by version control. In a real project, you will likely be doing this,
+but when trying out a build backend you might not think to add these even though
+they are required.
+
 {% endtab %} {% tab maturin Maturin %}
 
 Example `Cargo.toml` file:
@@ -277,6 +288,8 @@ PYBIND11_MODULE(_core, m) {
 
 {% endtab %} {% tab maturin Maturin %}
 
+Example `src/lib.rs` file:
+
 <!-- [[[cog
 with code_fence("rs"):
     print(maturin_src_lib_rs)