Merge branch 'master' into feature/491

Author: danimtb

changelog.rst

@@ -8,10 +8,39 @@ Check https://github.com/conan-io/conan for issues and more details about develo
 
 .. important::
 
-  Conan 1.4 shouldn't break any existing 1.0 recipe, or command line invocation. If it does, please report in github.
+  Conan 1.5 shouldn't break any existing 1.0 recipe, or command line invocation. If it does, please report in github.
   Please read more :ref:`about Conan stability<stability>`.
 
 
+1.5.0 (27-June-2018)
+--------------------
+
+- Feature: ``conan search <pkg-ref> -r=all`` now is able to search for binaries too in all remotes
+- Feature: Dependency graph improvements: ``build_requires`` are represented in the graph (visible in ``conan info``, also in the HTML graph). ``conan install`` and ``conan info`` commands shows extended information of the binaries status (represented in colors in HTML graph). The dependencies declaration order in recipes is respected (as long as it doesn't break the dependency graph order).
+- Feature: improved remote management, it is possible to get binaries from different remotes.
+- Feature: ``conan user`` command is now able to show authenticated users.
+- Feature: New ``pattern`` argument to ``tools.unzip()`` and ``tools.untargz`` functions, that allow efficient extraction of certain files only.
+- Feature : Added Manjaro support for ``SystemPackageTools``.
+- Feature: Added ``Macos`` ``version`` subsettings in the default ``settings.yml`` file, to account for the "min OSX version" configuration.
+- Feature: SCM helper argument to recursively clone submodules
+- Feature: SCM helper management of subfolder, allows using ``exports`` and ``exports_sources``, manage symlinks, and do not copy files that are ".gitignored". Also, works better in the local development flow.
+- Feature: Modifies user agent header to output the Conan client version and the Python version. Example: Conan/1.5.0 (Python 2.7.1)
+- Fix: The ``CMake`` helper now doesn't require a compiler input to deduce the default generator.
+- Fix: ``conan search <pattern>`` now works consistently in local cache and remotes.
+- Fix: proxy related environment variables are removed if ``conan.conf`` declares proxy configuration.
+- Fix: Fixed the parsing of invalid JSON when Microsoft ``vswhere`` tool outputs invalid non utf-8 text.
+- Fix: Applying ``winsdk`` and ``vcvars_ver`` to MSBuild and vcvars_command for VS 14 too.
+- Fix: Workspaces now support ``build_requires``
+- Fix: ``CMake`` helper now defines by default CMAKE_EXPORT_NO_PACKAGE_REGISTRY
+- Fix: settings constraints declared in recipes now don't error for single strings (instead of a list with a string element)
+- Fix: ``cmake_minimum_required()`` is now before ``project()`` in templates and examples.
+- Fix: CONAN_SYSREQUIRES_MODE=Disabled now doesn't try to udpate the system packages registry.
+- Bugfix: Fixed SCM origin path of windows folder (with backslashes)
+- Bugfix: Fixed SCM dictionary order when doing replacement.
+- Bugfix: Fixed auto-detection of apple-clang 10.0
+- Bugfix: Fixed bug when doing a ``conan search`` without registry file (just before installation)
+
+
 1.4.5 (22-June-2018)
 --------------------
 
@@ -22,8 +51,8 @@ Check https://github.com/conan-io/conan for issues and more details about develo
 --------------------
 
 - Bugfix: Fix link order with private requirements.
-- Bugfix: Removed duplicate `-std` flag in CMake < 3 or when the standard is not yet supported by `CMAKE_CXX_STANDARD`.
-- Bugfix: Check `scm` attribute to avoid breaking recipes with already defined one.
+- Bugfix: Removed duplicate ``-std`` flag in CMake < 3 or when the standard is not yet supported by ``CMAKE_CXX_STANDARD``.
+- Bugfix: Check ``scm`` attribute to avoid breaking recipes with already defined one.
 - Feature: Conan workspaces.
 
 
@@ -46,8 +75,8 @@ Check https://github.com/conan-io/conan for issues and more details about develo
 1.4.1 (31-May-2018)
 -------------------
 
-- Bugfix: Solved issue with symlinks making recipes to fail with `self.copy`.
-- Bugfix: Fixed c++20 standard usage with modern compilers and the creation of the ``settings.yml`` containing the settings values.
+- Bugfix: Solved issue with symlinks making recipes to fail with ``self.copy``.
+- Bugfix: Fixed c++20 standard usage with modern compilers and the creation of the *settings.yml* containing the settings values.
 - Bugfix: Fixed error with cased directory names in Windows.
 - BugFix: Modified confusing warning message in the SCM tool when the remote couldn't be detected.
 

conf.py

@@ -38,9 +38,9 @@
 ]
 
 # The short X.Y version.
-version = "1.4"
+version = "1.5"
 # The full version, including alpha/beta/rc tags.
-release = u'1.4.5'
+release = u'1.5.0'
 
 dir_path = os.path.dirname(os.path.realpath(__file__))
 if not os.path.exists(os.path.join(dir_path, "versions.json")):

deploy_gh_pages.py

@@ -70,31 +70,38 @@ def build_and_copy(branch, folder_name, versions_available, validate_links=False
         call("git commit --message 'committed version %s'" % folder_name, ignore_error=True)
 
 
-def deploy():
+def should_deploy():
     if not os.getenv("TRAVIS_BRANCH", None) == "master":
         print("Skipping deploy for not master branch")
-        return
+        return False
 
     if os.getenv("TRAVIS_PULL_REQUEST", "") != "false":
         print("Deploy skipped, This is a PR in the main repository")
-        return
+        return False
 
     if not os.getenv("GITHUB_API_KEY"):
         print("Deploy skipped, missing GITHUB_API_KEY. Is this a PR?")
-        return
+        return False
+
+    return True
 
+
+def deploy():
     call('git remote add origin-pages '
          'https://%s@github.com/conan-io/docs.git > /dev/null 2>&1' % os.getenv("GITHUB_API_KEY"))
     call('git push origin-pages gh-pages')
 
 
 if __name__ == "__main__":
-    config_git()
-    clean_gh_pages()
-
-    versions_dict = {"master": "1.4",
-                     "release/1.3.3": "1.3"}
-    for branch, folder_name in versions_dict.items():
-        build_and_copy(branch, folder_name, versions_dict, validate_links=branch == "master")
-
-    deploy()
+    if should_deploy():
+        config_git()
+        clean_gh_pages()
+        versions_dict = {"master": "1.4",
+                         "release/1.3.3": "1.3"}
+        for branch, folder_name in versions_dict.items():
+            build_and_copy(branch, folder_name, versions_dict, validate_links=branch == "master")
+
+        deploy()
+    else:
+        call("make html")
+        call("make linkcheck")

howtos/custom_generators.rst

@@ -42,10 +42,10 @@ that file. The **name of the generator** itself will be taken from the class nam
         def content(self):     
             return "whatever contents the generator produces"
             
-This class is just included in a ``conanfile.py`` that must contain also a ``Conanfile`` class
+This class is just included in a ``conanfile.py`` that must contain also a ``ConanFile`` class
 that implements the package itself, with the name of the package, the version, etc. This
 class typically has no ``source()``, ``build()``, ``package()``, and even the ``package_info()`` method is
-overriden as it doesn't have to define any include paths or library paths.
+overridden as it doesn't have to define any include paths or library paths.
 
 If you want to create a generator that creates more than one file, you can leave the ``filename()`` empty, and return a dictionary of
 filenames->contents in the ``content()`` method:

howtos/generic_ci_artifactory.rst

@@ -46,7 +46,7 @@ However, you can gather and upload that information using other CI infrastructur
     $ rm /tmp/traces.log
 
 5. Edit the `build_info.json` file to append ``name`` (build name), ``number`` (build number) and the ``started`` (started date) and
-   any other field that you need according to the `Build Info json format <https://github.com/JFrogDev/build-info>`_.
+   any other field that you need according to the `Build Info json format <https://github.com/jfrog/build-info>`_.
 
    The ``started`` field has to be in the format: ``yyyy-MM-dd'T'HH:mm:ss.SSSZ``
 

howtos/manage_shared_libraries/env_vars.rst

@@ -26,11 +26,9 @@ the right environment variable set, so they will be able to locate the (A) share
 Similarly if you use the :ref:`virtualenv generator<virtual_environment_generator>` and you
 activate it, you will get the paths needed to locate the shared libraries in your terminal.
 
-
 Example
 -------
 
-
 We are packaging a tool called ``toolA`` with a library and an executable that, for example, compress data.
 
 The package offers two flavors, shared library or static library (embedded in the executable of the tool and
@@ -51,7 +49,6 @@ you will need to have the shared library available.
         options = {"shared": [True, False]}
         default_options = "shared=False"
 
-
         def build(self):
             # build your shared library
 
@@ -67,40 +64,28 @@ you will need to have the shared library available.
             else:
                 ...
 
-
-        def package_info(self):
-            self.env_info.PATH.append(os.path.join(self.package_folder, "bin"))
-            if self.options.shared:
-                self.env_info.LD_LIBRARY_PATH.append(os.path.join(self.package_folder, "lib"))
-                self.env_info.DYLD_LIBRARY_PATH.append(os.path.join(self.package_folder, "lib"))
-
-
-
 Using the tool from a different package
 ---------------------------------------
 
 If we are creating now a package that uses the ``ToolA`` executable to compress some data. You can
-call directly to the ``toolA.exe``, the required environment variables to locate both the executable
-and the shared libraries are automatically available:
+execute directly ``toolA`` using RunEnvironment build helper to set the environment variables accordingly:
 
 .. code-block:: python
 
     import os
     from conans import tools, ConanFile
 
     class PackageB(ConanFile):
-        ....
         name = "packageB"
         version = "1.0"
         requires = "toolA/1.0@myuser/stable"
 
-
         def build(self):
-            ...
-            # we can call directly the ``toolA`` executable. the shared library will be located too
             exe_name = "toolA.exe" if self.settings.os == "Windows" else "toolA"
-            self.run("%s --someparams" % exe_name)
-            ...
+            env_build = RunEnvironment(self)
+            with tools.environment_append(env_build.vars):
+                self.run("%s --someparams" % exe_name)
+                ...
 
 Building an application using the shared library from ``toolA``
 ---------------------------------------------------------------
@@ -109,9 +94,8 @@ As we are building a final application, probably we will want to distribute it t
 shared library from the ``toolA``, so we can use the :ref:`Imports<imports_txt>` to import the required
 shared libraries to our user space.
 
-**conanfile.txt**
-
 .. code-block:: python
+   :caption: *conanfile.txt*
 
     [requires]
     toolA/1.0@myuser/stable
@@ -127,8 +111,7 @@ shared libraries to our user space.
     lib, *.dylib* -> ./bin # Copies all dylib files from packages lib folder to my "bin" folder
     lib, *.so* -> ./bin # Copies all dylib files from packages lib folder to my "bin" folder
 
-
-**In the terminal window and build the project:**
+Now you can build the project:
 
 .. code-block:: bash
 
@@ -148,9 +131,8 @@ In Linux you still need to set the ``LD_LIBRARY_PATH``, or in OSX, the ``DYLD_LI
 
    $ cd bin && LD_LIBRARY_PATH=$(pwd) && ./mytool
 
-
 Using shared libraries from dependencies
-------------------------------------------
+----------------------------------------
 
 If you are executing something that depends on shared libraries belonging to your dependencies, such shared libraries have to be found at
 runtime. In Windows, it is enough if the package added its binary folder to the system ``PATH``. In Linux and OSX, it is necessary that the
@@ -159,35 +141,25 @@ runtime. In Windows, it is enough if the package added its binary folder to the
 Security restrictions might apply in OSX
 (`read this thread <https://stackoverflow.com/questions/35568122/why-isnt-dyld-library-path-being-propagated-here>`_), so the
 ``DYLD_LIBRARY_PATH`` environment variable is not directly transferred to the child process. In that case, you have to use it explicitly in
+<<<<<<< HEAD
 your conanfile.py:
+=======
+your *conanfile.py*:
+>>>>>>> master
 
 .. code-block:: python
 
     def test(self):
         # self.run('./myexe") # won't work, even if 'DYLD_LIBRARY_PATH' is in the env
-        self.run('DYLD_LIBRARY_PATH=%s ./myexe" % os.environ['DYLD_LIBRARY_PATH'])
-
+        with tools.environment_append({"DYLD_LIBRARY_PATH": [self.deps_cpp_info["toolA"].lib_paths]}):
+            self.run('DYLD_LIBRARY_PATH=%s ./myexe" % os.environ['DYLD_LIBRARY_PATH'])
 
+Or you could use ``RunEnvironment`` helper described above.
 
-Using the **virtualenv** generator
-----------------------------------
-
-We could also use a :ref:`virtualenv generator<virtual_environment_generator>` to get the
-``toolA`` executable available:
-
-**conanfile.txt**
-
-.. code-block:: python
-
-    [requires]
-    toolA/1.0@myuser/stable
-
-    [options]
-    toolA:shared=True
-
-    [generators]
-    virtualenv
+Using ``virtualrunenv`` generator
+---------------------------------
 
+<<<<<<< HEAD
 
 **In the terminal window:**
 
@@ -207,8 +179,13 @@ the environment variables pointing to the "lib" and "bin" folders.
 
 
 **conanfile.txt**
+=======
+:ref:`virtualrunenv generator<virtual_run_environment_generator>` will set the environment variables ``PATH``, ``LD_LIBRARY_PATH``,
+``DYLD_LIBRARY_PATH`` pointing to *lib* and *bin* folders automatically.
+>>>>>>> master
 
 .. code-block:: python
+   :caption: *conanfile.txt*
 
     [requires]
     toolA/1.0@myuser/stable
@@ -217,13 +194,20 @@ the environment variables pointing to the "lib" and "bin" folders.
     toolA:shared=True
 
     [generators]
-    virtualenv
-
+    virtualrunenv
 
-**In the terminal window:**
+In the terminal window:
 
 .. code-block:: bash
 
+<<<<<<< HEAD
     conan install .
     source activate
     toolA --someparams
+=======
+    $ conan install .
+    $ source activate_run
+    $ toolA --someparams
+    # Only For Mac OS users to avoid restrictions:
+    $ DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH toolA --someparams
+>>>>>>> master

reference/build_helpers/cmake.rst

@@ -155,6 +155,8 @@ The CMake helper will automatically append some definitions based on your settin
 +-------------------------------------------+------------------------------------------------------------------------------------------------------------------------------+
 | CONAN_STD_CXX_FLAG                        |  From setting ``cppstd``. Flag for compiler directly (for CMake < 3.1)                                                       |
 +-------------------------------------------+------------------------------------------------------------------------------------------------------------------------------+
+| CMAKE_EXPORT_NO_PACKAGE_REGISTRY          |  By default, disable the package registry                                                                                    |
++-------------------------------------------+------------------------------------------------------------------------------------------------------------------------------+
 
 
 

reference/commands/consumer/config.rst

@@ -71,8 +71,20 @@ These are the special files and the rules applied to merge them:
 | config/conan.conf              | Merges the variables, overriding only the declared variables         |
 +--------------------------------+----------------------------------------------------------------------+
 
+The file *remotes.txt* is the only file listed above which does not have a direct counterpart in
+the ``~/.conan`` folder. Its format is a list of entries, one on each line, with the form
+
+.. code-block::
+
+    [remote name] [remote url] [bool]
+    
+where ``[bool]`` (either ``True`` or ``False``) indicates whether SSL should be used to verify that remote. 
+
 The local cache *registry.txt* file contains the remotes definitions, as well as the mapping from packages
-to remotes. In general it is not a good idea to add it to the installed files.
+to remotes. In general it is not a good idea to add it to the installed files. That being said, the remote
+definitions part of the *registry.txt* file uses the format required for *remotes.txt*, so you may find it
+provides a helpful starting point when writing a *remotes.txt* to be packaged in a Conan
+client configuration.
 
 The specified URL will be stored in the ``general.config_install`` variable of the ``conan.conf`` file,
 so following calls to :command:`conan config install` command doesn't need to specify the URL.

reference/conanfile/attributes.rst

@@ -520,9 +520,9 @@ something like `C:/.conan/tmpdir`. All the folder layout in the conan cache is m
 This attribute will not have any effect in other OS, it will be discarded.
 
 From Windows 10 (ver. 10.0.14393), it is possible to opt-in disabling the path limits. Check `this link
-<https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath>`_ for more info.
-Latest python installers might offer to enable this while installing python. With this limit removed, the ``short_paths`` functionality is totally unnecessary.
-Please note that this only works with Python 3.6 and newer.
+<https://docs.microsoft.com/es-es/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation>`_ for more info.
+Latest python installers might offer to enable this while installing python. With this limit removed, the ``short_paths`` functionality is
+totally unnecessary. Please note that this only works with Python 3.6 and newer.
 
 .. _no_copy_source:
 
@@ -815,6 +815,9 @@ Used to clone/checkout a repository. It is a dictionary with the following possi
 - **username** (Optional, Defauted to ``None``): When present, it will be used as the login to authenticate with the remote.
 - **password** (Optional, Defauted to ``None``): When present, it will be used as the password to authenticate with the remote.
 - **verify_ssl** (Optional, Defaulted to ``True``): Verify SSL certificate of the specified **url**.
+- **submodule** (Optional, Defaulted to ``None``):
+   - ``shallow``: Will sync the git submodules using ``submodule sync``
+   - ``recursive``: Will sync the git submodules using ``submodule sync --recursive``
 
 To know more about the usage of ``scm`` check: