From a6143b5b79c5b641831a845594d6c8d8e586fc52 Mon Sep 17 00:00:00 2001 From: danimtb Date: Mon, 23 Mar 2020 10:57:34 +0100 Subject: [PATCH] Fix broken links and remove trailing backlash --- creating_packages/define_abi_compatibility.rst | 4 ++-- devtools/running_packages.rst | 6 +++--- integrations/cross_platform/android.rst | 4 ++-- integrations/cross_platform/emscripten.rst | 4 ++-- integrations/deployment/appimage.rst | 2 +- integrations/deployment/flatpak.rst | 4 ++-- integrations/deployment/snap.rst | 2 +- integrations/deployment/system_package_manager.rst | 2 +- reference/build_helpers/visual_studio.rst | 2 +- systems_cross_building/windows_subsystems.rst | 2 +- videos.rst | 2 +- 11 files changed, 17 insertions(+), 17 deletions(-) diff --git a/creating_packages/define_abi_compatibility.rst b/creating_packages/define_abi_compatibility.rst index 476ee53f401..8f27620ddb8 100644 --- a/creating_packages/define_abi_compatibility.rst +++ b/creating_packages/define_abi_compatibility.rst @@ -74,7 +74,7 @@ Defining a Custom package_id() ------------------------------ The default ``package_id()`` uses the ``settings`` and ``options`` directly as defined, and assumes the -`semantic versioning `_ for dependencies is defined in ``requires``. +`semantic versioning `_ for dependencies is defined in ``requires``. This ``package_id()`` method can be overridden to control the package ID generation. Within the ``package_id()``, we have access to the ``self.info`` object, which is hashed to compute the binary ID and contains: @@ -394,7 +394,7 @@ When defining a package ID for model dependencies, it is necessary to take into Versioning Schema +++++++++++++++++ -By default Conan assumes `semver `_ compatibility. For example, if a version changes from minor **2.0** to **2.1**, Conan will +By default Conan assumes `semver `_ compatibility. For example, if a version changes from minor **2.0** to **2.1**, Conan will assume that the API is compatible (headers not changing), and that it is not necessary to build a new binary for it. This also applies to patches, whereby changing from **2.1.10** to **2.1.11** doesn't require a re-build. diff --git a/devtools/running_packages.rst b/devtools/running_packages.rst index 5de8fb66786..5bb14d20df8 100644 --- a/devtools/running_packages.rst +++ b/devtools/running_packages.rst @@ -348,7 +348,7 @@ Even if your application doesn't use directly any of these functions, they are o so, in practice, it's almost always in actual use. There are other implementations of the C standard library that present the same challenge, such as -`newlib `_ or `musl `_, used for embedded development. +`newlib `_ or `musl `_, used for embedded development. To illustrate the problem, a simple hello-world application compiled in a modern Ubuntu distribution will give the following error when it is run in a Centos 6 one: @@ -382,7 +382,7 @@ C++ standard library ++++++++++++++++++++ Usually, the default C++ standard library is `libstdc++ `_, but -`libc++ `_ and `stlport `_ are other well-known implementations. +`libc++ `_ and `stlport `_ are other well-known implementations. Similarly to the standard C library `glibc`, running the application linked with libstdc++ in the older system may result in an error: @@ -415,7 +415,7 @@ detailed information. System API (system calls) +++++++++++++++++++++++++ -New system calls are often introduced with new releases of `Linux kernel `_. If the application, or 3rd-party +New system calls are often introduced with new releases of `Linux kernel `_. If the application, or 3rd-party libraries, want to take advantage of these new features, they sometimes directly refer to such system calls (instead of using wrappers provided by ``glibc``). diff --git a/integrations/cross_platform/android.rst b/integrations/cross_platform/android.rst index d2b6c6e8c8d..eae735878e9 100644 --- a/integrations/cross_platform/android.rst +++ b/integrations/cross_platform/android.rst @@ -3,7 +3,7 @@ |android_logo| Android ____________________________ -There are several ways to cross-compile packages for `Android `__ platform via conan. +There are several ways to cross-compile packages for `Android `__ platform via conan. Using android_ndk_installer package (build require) ========================================================= @@ -69,7 +69,7 @@ By adjusting ``arch`` setting, you may cross-compile for ``x86`` and ``x86_64`` Using Docker images =================== -If you're using `Docker `_ for builds, you may consider using docker images from the +If you're using `Docker `_ for builds, you may consider using docker images from the `Conan Docker Tools `_ repository. Currently, Conan Docker Tools provide the following Android images: diff --git a/integrations/cross_platform/emscripten.rst b/integrations/cross_platform/emscripten.rst index 0eab243e205..f49673a7a50 100644 --- a/integrations/cross_platform/emscripten.rst +++ b/integrations/cross_platform/emscripten.rst @@ -3,7 +3,7 @@ |emscripten_logo| Emscripten ____________________________ -It should be possible to build packages for `Emscripten `__ (`asm.js `_) via the following conan profile: +It should be possible to build packages for `Emscripten `__ (`asm.js `_) via the following conan profile: .. code-block:: text @@ -19,7 +19,7 @@ It should be possible to build packages for `Emscripten `_ (Web Assembly): +And the following conan profile is required for the `WASM `_ (Web Assembly): .. code-block:: text diff --git a/integrations/deployment/appimage.rst b/integrations/deployment/appimage.rst index 2710652f95d..e6881de453a 100644 --- a/integrations/deployment/appimage.rst +++ b/integrations/deployment/appimage.rst @@ -3,7 +3,7 @@ AppImage -------- -`AppImage `_ (former ``klik``, ``PortableLinuxApps``) is a format for Linux portable applications. Its major advantages are: +`AppImage `_ (former ``klik``, ``PortableLinuxApps``) is a format for Linux portable applications. Its major advantages are: - It does not require root permissions. - It does not require to install any application (it uses :command:`chmod +x`). diff --git a/integrations/deployment/flatpak.rst b/integrations/deployment/flatpak.rst index 12152cd68c4..ed82bf942f7 100644 --- a/integrations/deployment/flatpak.rst +++ b/integrations/deployment/flatpak.rst @@ -3,14 +3,14 @@ Flatpak ------- -`Flatpak `_ (former ``xdg-app``) is a package management system to distribute desktop applications for Linux. It is based on `OSTree `_. +`Flatpak `_ (former ``xdg-app``) is a package management system to distribute desktop applications for Linux. It is based on `OSTree `_. Flatpak is `RedHat `_ initiative. Unlike :ref:`AppImage `, usually applications are distributed via `flathub `_ store, and require a special runtime to install applications on target machines. The major advantage of ``Flatpak`` is sandboxing: each application runs in its own isolated environment. ``Flatpak`` provides fine-grained control to system resources (e.g. network, bluetooth, host filesystem, etc.). ``Flatpak`` also offers a set of runtimes for various Linux desktop applications, e.g. -`Freedesktop `_, `GNOME `_ and `KDE `_. +`Freedesktop `_, `GNOME `_ and `KDE `_. The `packaging process `__ is: diff --git a/integrations/deployment/snap.rst b/integrations/deployment/snap.rst index 0b29de6f925..8928cc7a555 100644 --- a/integrations/deployment/snap.rst +++ b/integrations/deployment/snap.rst @@ -6,7 +6,7 @@ Snap `Snap `_ is the package management system available for the wide range of Linux distributions. Unlike :ref:`AppImage `, Snap requires a daemon (``snapd``) installed in the system in order to operate. Under the hood, **Snap** is based on `SquashFS `_. -``Snap`` is `Canonical `_ initiative. Usually, applications are distributed via `snapcraft `_ store, but it's not mandatory. +``Snap`` is `Canonical `_ initiative. Usually, applications are distributed via `snapcraft `_ store, but it's not mandatory. ``Snap`` provides fine-grained control to system resources (e.g. camera, removable media, network, etc.). The major advantage is `plug-in system `_, which allows to easily integrate ``Snap`` with different languages and build systems (e.g. CMake, autotools, etc.). diff --git a/integrations/deployment/system_package_manager.rst b/integrations/deployment/system_package_manager.rst index 3ecdff85e4d..00d53bfa142 100644 --- a/integrations/deployment/system_package_manager.rst +++ b/integrations/deployment/system_package_manager.rst @@ -10,7 +10,7 @@ method is very convenient for deployment and distribution as it is natively inte distributions in order to create different packages for them. - If you want to target different distros, then you need to create one package per supported distro (likely one for - `Ubuntu `_, one for `Arch Linux `_, etc.), and formats or guidelines for each distro might differ significantly + `Ubuntu `_, one for `Arch Linux `_, etc.), and formats or guidelines for each distro might differ significantly Check out the sections :ref:`makeself `, :ref:`AppImage `, :ref:`Flatpak ` and :ref:`Snap ` for information on how to create distribution-agnostic packages. diff --git a/reference/build_helpers/visual_studio.rst b/reference/build_helpers/visual_studio.rst index 0ee0f068d56..7a0a4c025b1 100644 --- a/reference/build_helpers/visual_studio.rst +++ b/reference/build_helpers/visual_studio.rst @@ -128,7 +128,7 @@ Parameters: - **output_binary_log** (Optional, Defaulted to ``None``): Sets ``/bl`` flag. If set to ``True`` then MSBuild will output a binary log file called *msbuild.binlog* in the working directory. It can also be used to set the name of log file like this ``output_binary_log="my_log.binlog"``. This parameter is only supported - `starting from MSBuild version 15.3 and onwards `_. + `starting from MSBuild version 15.3 and onwards `_. - **property_file_name** (Optional, Defaulted to ``None``): Sets ``p:ForceImportBeforeCppTargets``. When ``None`` it will generate a file named *conan_build.props*. You can specify a different name for the generated properties file. - **verbosity** (Optional, Defaulted to ``None``): Sets the ``/verbosity`` flag to the specified verbosity level. Possible values are diff --git a/systems_cross_building/windows_subsystems.rst b/systems_cross_building/windows_subsystems.rst index f681f5a5dac..0562bffbd55 100644 --- a/systems_cross_building/windows_subsystems.rst +++ b/systems_cross_building/windows_subsystems.rst @@ -64,7 +64,7 @@ Controlling the build environment Building software in a Windows subsystem for a different compiler than MinGW can sometimes be painful. The reason is how the subsystem finds your compiler/tools in your system. -For example, the `icu `_ library requires Visual Studio to be built in Windows, but also a subsystem +For example, the `icu `_ library requires Visual Studio to be built in Windows, but also a subsystem able to build the Makefile. A very common problem and example of the pain is the ``link.exe`` program. In the Visual Studio suite, ``link.exe`` is the linker, but in the ``MSYS2`` environment the ``link.exe`` is a tool to manage symbolic links. diff --git a/videos.rst b/videos.rst index 19b5aeb5c91..33bb33fc423 100644 --- a/videos.rst +++ b/videos.rst @@ -102,7 +102,7 @@ Videos and links

-- "Conan.io C++ Package Manager demo with SFML" by `Charl Botha `_ +- "Conan.io C++ Package Manager demo with SFML" by `Charl Botha `_ .. raw:: html