Fix broken links and remove trailing backlash

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 <https://semver.org/>`_ for dependencies is defined in ``requires``.
+`semantic versioning <https://semver.org>`_ 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 <https://semver.org/>`_ compatibility. For example, if a version changes from minor **2.0** to **2.1**, Conan will
+By default Conan assumes `semver <https://semver.org>`_ 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.
 

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 <https://sourceware.org/newlib/>`_ or `musl <https://www.musl-libc.org/>`_, used for embedded development.
+`newlib <https://sourceware.org/newlib/>`_ or `musl <https://www.musl-libc.org>`_, 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++ <https://gcc.gnu.org/onlinedocs/libstdc++/>`_, but
-`libc++ <https://libcxx.llvm.org/>`_ and `stlport <http://www.stlport.org/>`_ are other well-known implementations.
+`libc++ <https://libcxx.llvm.org>`_ and `stlport <http://www.stlport.org>`_ 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 <https://www.kernel.org/>`_. If the application, or 3rd-party
+New system calls are often introduced with new releases of `Linux kernel <https://www.kernel.org>`_. 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``).
 

integrations/cross_platform/android.rst

@@ -3,7 +3,7 @@
 |android_logo| Android
 ____________________________
 
-There are several ways to cross-compile packages for `Android <https://www.android.com/>`__ platform via conan.
+There are several ways to cross-compile packages for `Android <https://www.android.com>`__ 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 <https://www.docker.com/>`_ for builds, you may consider using docker images from the
+If you're using `Docker <https://www.docker.com>`_ for builds, you may consider using docker images from the
 `Conan Docker Tools <https://github.com/conan-io/conan-docker-tools>`_ repository.
 
 Currently, Conan Docker Tools provide the following Android images:

integrations/cross_platform/emscripten.rst

@@ -3,7 +3,7 @@
 |emscripten_logo| Emscripten
 ____________________________
 
-It should be possible to build packages for `Emscripten <https://emscripten.org/>`__ (`asm.js <http://asmjs.org/>`_) via the following conan profile:
+It should be possible to build packages for `Emscripten <https://emscripten.org>`__ (`asm.js <http://asmjs.org>`_) via the following conan profile:
 
 .. code-block:: text
 
@@ -19,7 +19,7 @@ It should be possible to build packages for `Emscripten <https://emscripten.org/
   emsdk_installer/1.38.29@bincrafters/stable
   [env]
 
-And the following conan profile is required for the `WASM <https://webassembly.org/>`_ (Web Assembly):
+And the following conan profile is required for the `WASM <https://webassembly.org>`_ (Web Assembly):
 
 .. code-block:: text
 

integrations/deployment/appimage.rst

@@ -3,7 +3,7 @@
 AppImage
 --------
 
-`AppImage <https://appimage.org/>`_ (former ``klik``, ``PortableLinuxApps``) is a format for Linux portable applications. Its major advantages are:
+`AppImage <https://appimage.org>`_ (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`).

integrations/deployment/flatpak.rst

@@ -3,14 +3,14 @@
 Flatpak
 -------
 
-`Flatpak <https://flatpak.org/>`_ (former ``xdg-app``) is a package management system to distribute desktop applications for Linux. It is based on `OSTree <https://ostree.readthedocs.io/en/latest/manual/introduction/>`_. 
+`Flatpak <https://flatpak.org>`_ (former ``xdg-app``) is a package management system to distribute desktop applications for Linux. It is based on `OSTree <https://ostree.readthedocs.io/en/latest/manual/introduction/>`_.
 Flatpak is `RedHat <https://www.redhat.com/en>`_ initiative.
 
 Unlike :ref:`AppImage <deployment_appimage>`, usually applications are distributed via `flathub <https://flathub.org>`_ 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 <https://www.freedesktop.org/wiki/>`_, `GNOME <https://www.gnome.org/>`_ and `KDE <https://kde.org/>`_.
+`Freedesktop <https://www.freedesktop.org/wiki/>`_, `GNOME <https://www.gnome.org>`_ and `KDE <https://kde.org>`_.
 
 The `packaging process <http://docs.flatpak.org/en/latest/first-build.html>`__ is:
 

integrations/deployment/snap.rst

@@ -6,7 +6,7 @@ Snap
 `Snap <https://snapcraft.io/>`_ is the package management system available for the wide range of Linux distributions.
 Unlike :ref:`AppImage <deployment_appimage>`, Snap requires a daemon (``snapd``) installed in the system in order to operate. Under the hood, **Snap** is based on
 `SquashFS <https://github.com/plougher/squashfs-tools>`_. 
-``Snap`` is `Canonical <https://canonical.com/>`_ initiative. Usually, applications are distributed via `snapcraft <https://snapcraft.io/store>`_ store, but it's not mandatory.
+``Snap`` is `Canonical <https://canonical.com>`_ initiative. Usually, applications are distributed via `snapcraft <https://snapcraft.io/store>`_ 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 <https://snapcraft.io/docs/supported-plugins>`_, which allows to easily integrate ``Snap`` with different languages and build systems (e.g. CMake, autotools, etc.).
 

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 <https://ubuntu.com/>`_, one for `Arch Linux <https://www.archlinux.org/>`_, etc.), and formats or guidelines for each distro might differ significantly
+  `Ubuntu <https://ubuntu.com>`_, one for `Arch Linux <https://www.archlinux.org>`_, etc.), and formats or guidelines for each distro might differ significantly
 
 Check out the sections :ref:`makeself <deployment_makeself>`, :ref:`AppImage <deployment_appimage>`, 
 :ref:`Flatpak <deployment_flatpak>` and :ref:`Snap <deployment_snap>` for information on how to create distribution-agnostic packages.

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 <http://msbuildlog.com/>`_.
+      `starting from MSBuild version 15.3 and onwards <https://msbuildlog.com>`_.
     - **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

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 <http://site.icu-project.org/>`_ library requires Visual Studio to be built in Windows, but also a subsystem
+For example, the `icu <http://site.icu-project.org>`_ 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.

videos.rst

@@ -102,7 +102,7 @@ Videos and links
       <br/><br/>
 
 
-- "Conan.io C++ Package Manager demo with SFML" by `Charl Botha <https://charlbotha.com/>`_
+- "Conan.io C++ Package Manager demo with SFML" by `Charl Botha <https://charlbotha.com>`_
 
   .. raw:: html