{% block body %}{% endblock %} @@ -191,6 +198,14 @@ {% endif %} + + + + + {# STICKY NAVIGATION #} {% if theme_sticky_navigation %} {% endif %} + + + {%- block footer %} {% endblock %} diff --git a/_themes/conan/searchbox.html b/_themes/conan/searchbox.html index 606f5c8c9d76..4fc1e7a71c8e 100644 --- a/_themes/conan/searchbox.html +++ b/_themes/conan/searchbox.html @@ -1,9 +1,9 @@ {%- if builder != 'singlehtml' %} -
+ {%- endif %} diff --git a/_themes/conan/static/css/search.css b/_themes/conan/static/css/search.css new file mode 100644 index 000000000000..37e15f232513 --- /dev/null +++ b/_themes/conan/static/css/search.css @@ -0,0 +1,112 @@ +input{ + border-radius: 5px; +} + +.select2-dropdown{ + padding-top: 20px; +} + + +.select2-container--default .select2-results__option--highlighted[aria-selected]{ + background-color: white; +} + + +.select2-container--default .select2-results>.select2-results__options { + overflow-y: none; + max-height: none; +} + +.select2-results__option:hover, select2-results__option:active{ + background-color: white; + +} + + +.select2-dropdown { + padding: 0px; +} + +.select2-selection__choice{ + display:none; + min-height: 200px; +} + + +.res_section{ + width: 95%; +} + +.res_section{ + font-family: "Lato","proxima-nova","Helvetica Neue", "Arial", "sans-serifbody"; + margin: 10px; +} + +.res_section span{ + font-size: 1em; + border-bottom: 1px solid #CCCCCC; + margin-bottom: 2px; + width: 100%; + display: block; + padding: 0 10px 0 5px; + margin-bottom: 10px; + color: #222222; +} + +.res_section span.search_match{ + display:inline; + border: none; + width: none; + padding: 0px; + margin: 0px; + color: #0099FF; + +} + + +.res_section .res_subsection{ + font-size: 0.9em; + margin-bottom: 2px; + margin-left: 40px; + width: 20%; + display: inline-block; + border-right: 1px solid #CCCCCC; + text-align: right; + padding-right: 20px; + color: #AAAAAA; +} + + + +.res_section .res_text{ + font-family: sans; + font-size: 0.9em; + margin-bottom: 2px; + margin-left: 20px; + width: 65%; + display: inline-block; + color: #222222; + vertical-align: top; +} + +#search{ + height: 24px; +} + +.wy-side-nav-search a{ + margin-bottom: 0px; +} + +#breadcrumbs{ + margin-bottom:5px; +} + +.dropdown-wrapper{ + border: none; +} + +.select2-results__option.loading-results, +.select2-results__option.select2-results__option--load-more { + padding-left: 35px; + background-position: 10px 50%; +} \ No newline at end of file diff --git a/_themes/conan/static/js/search.js b/_themes/conan/static/js/search.js new file mode 100644 index 000000000000..ca8503a378e4 --- /dev/null +++ b/_themes/conan/static/js/search.js @@ -0,0 +1,64 @@ + +function decorateResult(result) { + if(result.loading){ + return "Searching..." + } + if(result.parent_title == null){ + return ""; + } + var $ret = $('
' + result.parent_title + '
' + result.title + '
' + result.relevant_text + '
'); + return $ret; +}; + + +function initSearch(version){ + + $(document).ready(function() { + + $('#search').select2({ + placeholder: "Search Conan Docs", + allowClear: true, + templateResult: decorateResult, + minimumInputLength: 2, + ajax: { + delay: 350, + method: "GET", + dataType: 'json', + url: 'https://3ghmj80y32.execute-api.us-east-1.amazonaws.com/api/search', + //url: 'http://127.0.0.1:8000/search', + data: function (params) { + if(!params.term){ + return -1; + } + var query = { + query: params.term, + version: version + } + return query; + }, + async: false, + crossDomain: true, + contentType: 'application/json', + processResults: function (data) { + // Transforms the top-level key of the response object from 'items' to 'results' + console.log(data["time"]); + var elements = [] + data.results.forEach(function(el) { + el.id = el.slug; + el.text = el.title; + if(!el.parent_title){ + el.parent_title = el.text; + } + if(!el.relevant_text){ + el.relevant_text = el.title; + } + elements.push(el); + }); + return { + results: elements + }; + } + } + }); + }); + } diff --git a/changelog.rst b/changelog.rst index 2ea64ba76464..6041428ab093 100644 --- a/changelog.rst +++ b/changelog.rst @@ -18,10 +18,76 @@ Check https://github.com/conan-io/conan for issues and more details about develo .. important:: - Conan 1.15 shouldn't break any existing 1.0 recipe or command line invocation. If it does, please submit a report on GitHub. + Conan 1.16 shouldn't break any existing 1.0 recipe or command line invocation. If it does, please submit a report on GitHub. Read more about the :ref:`Conan stability commitment`. +1.16.1 (14-Jun-2019) +-------------------- + +- Feature: Print nicer error messages when receive an error from Artifactory. `#5326 `_ +- Fix: Make ``conan config get storage.path`` return an absolute, resolved path `#5350 `_ +- Fix: Skipped the compiler version check in the cmake generator when a `-s compiler.toolset` is specified (Visual Studio). `#5348 `_ +- Fix: Constraint transitive dependency ``typed-ast`` (required by astroid) in python3.4, as they stopped releasing wheels, and it fails to build in some Windows platforms with older SDKs. `#5324 `_ +- Fix: Accept v140 and VS 15.0 for CMake generator (#5318) `#5321 `_ +- Fix: Accept only .lib and .dll as Visual extensions (#5316) `#5319 `_ +- Bugfix: Do not copy directories inside a symlinked one `#5342 `_ +- Bugfix: Conan was retrying the upload when failed with error 400 (request error). `#5326 `_ + + +1.16.0 (4-Jun-2019) +------------------- + +- Feature: The :command:`conan upload` command can receive now the full package reference to upload a binary package. The `-p` argument is now deprecated. `#5224 `_ . Docs `here `__ +- Feature: Add hooks `pre_package_info` and `post_package_info` `#5223 `_ . Docs `here `__ +- Feature: New build mode `--build cascade` that forces building from sources any node with dependencies also built from sources. `#5218 `_ . Docs `here `__ +- Feature: Print errors and warnings to `stderr` `#5206 `_ +- Feature: New ``conan new --template=mytemplate`` to initialize recipes with your own templates `#5189 `_ . Docs `here `__ +- Feature: Allow using wildcards to remove system requirements sentinel from cache. `#5176 `_ . Docs `here `__ +- Feature: Implement conan.conf ``retry`` and ``retry-wait`` and ``CONAN_RETRY`` and ``CONAN_RETRY_WAIT`` to configure all retries for all transfers, including upload, download, and ``tools.download()``. `#5174 `_ . Docs `here `__ +- Feature: Support yaml lists in workspace ``root`` field. `#5156 `_ . Docs `here `__ +- Feature: Add gcc 8.3 and 9.1 new versions to default *settings.yml* `#5112 `_ +- Feature: Retry upload or download for error in response message (e.g. status is '500') `#4984 `_ +- Fix: Do not retry file transfer operations for 401 and 403 auth and permissions errors. `#5278 `_ +- Fix: Copy symlinked folder when using `merge_directories` function `#5237 `_ +- Fix: Add the ability to avoid the `/verbosity` argument in CMake command line for MSBuild `#5220 `_ . Docs `here `__ +- Fix: self.copy with symlinks=True does not copy symlink if the .conan directory is a symlink #5114 `#5125 `_ +- Fix: Export detected_os from tools.oss (#5101) `#5102 `_ . Docs `here `__ +- Fix: Use `revision` as the SVN's `peg_revision` (broken for an edge case) `#5029 `_ +- Bugfix: ``--update`` was not updating ``python_requires`` using version ranges. `#5265 `_ +- Bugfix: ``visual_studio`` generator only adds ".lib" extension for lib names without extension, otherwise (like ".a") respect it. `#5254 `_ +- Bugfix: Fix :command:`conan search` command showing revisions timestamps in a different time offset than UTC. `#5232 `_ +- Bugfix: Meson build-helper gets correct compiler flags, AutoTools build environment adds compiler.runtime flags `#5222 `_ +- Bugfix: The `cmake_multi` generator was not managing correctly the `RelWithDebInfo` and `MinSizeRel` build types. `#5221 `_ +- Bugfix: Check that registry file exists before removing it `#5219 `_ +- Bugfix: do not append "-T " if generator doesn't support it `#5201 `_ +- Bugfix: :command:`conan download` always retrieve the sources, also with ``--recipe`` argument, which should only skip download binaries, not the sources. `#5194 `_ +- Bugfix: Using `scm` declared in a superclass failed exporting the recipe with the error `ERROR: The conanfile.py defines more than one class level 'scm' attribute`. `#5185 `_ +- Bugfix: Conan command returns 6 (Invalid configuration) also when the settings are restricted in the recipe `#5178 `_ +- Bugfix: Make sure that proxy "http_proxy", "https_proxy", "no_proxy" vars are correctly removed if custom ones are defined in the conan.conf. Also, avoid using ``urllib.request.getproxies()``, they are broken. `#5162 `_ +- Bugfix: Use `copy()` for deploy generator so that permissions of files are preserved. Required if you want to use the deploy generator to deploy executables. `#5136 `_ + + +1.15.4 +------ + +- Fix: Accept v140 and VS 15.0 for CMake generator (#5318) `#5331 `_ +- Fix: Constraint transitive dependency typed-ast (required by astroid) in python3.4, as they stopped releasing wheels, and it fails to build in some Windows platforms with older SDKs. `#5331 `_ + + +1.15.3 +------ + +- Please, do not use this version, there was a critical error in the release process and changes from the 1.16 branch were merged. + + +1.15.2 (31-May-2019) +-------------------- + +- Bugfix: Fix bug with python-requires not being updated with ``--update`` if using version-ranges. `#5266 `_ +- Bugfix: Fix computation of ancestors performance regression `#5260 `_ + + 1.15.1 (16-May-2019) --------------------- diff --git a/conf.py b/conf.py index cb9696f08352..c4219d4c5d96 100644 --- a/conf.py +++ b/conf.py @@ -39,9 +39,9 @@ ] # The short X.Y version. -version = "1.15" +version = "1.16" # The full version, including alpha/beta/rc tags. -release = u'1.15.1' +release = u'1.16.1' dir_path = os.path.dirname(os.path.realpath(__file__)) if not os.path.exists(os.path.join(dir_path, "versions.json")): diff --git a/creating_packages/package_approaches.rst b/creating_packages/package_approaches.rst index 6e7446bef629..e2777cd7ee3f 100644 --- a/creating_packages/package_approaches.rst +++ b/creating_packages/package_approaches.rst @@ -74,17 +74,15 @@ mistake could be a very risky issue. Read more about this in :ref:`method_package_info`. - .. _packaging_approach_N_1: N configs -> 1 package ---------------------- -You may want to package both debug and release artifacts in the same package, -so it can be consumed from IDEs like Visual Studio. This will change the debug/release configuration from the -IDE, without having to specify it in the command line. This type of package can contain different -artifacts for different configurations, and can be used for example to include both the release and debug version of the "hello" -library, in the same package. +You may want to package both debug and release artifacts in the same package, so it can be consumed from IDEs like Visual Studio. This will +change the debug/release configuration from the IDE, without having to specify it in the command line. This type of package can contain +different artifacts for different configurations and can be used to include both the release and debug version of a library in the same +package. .. image:: /images/multi_conf_packages.png :height: 300 px @@ -93,54 +91,44 @@ library, in the same package. .. note:: - A complete working example of the following code can be found in a github repo. You should be - able to run: + A complete working example of the following code can be found in the examples repo: https://github.com/conan-io/examples .. code:: bash - $ git clone https://github.com/memsharded/hello_multi_config - $ cd hello_multi_config - $ conan create . user/channel -s build_type=Release - $ conan create . user/channel -s build_type=Debug --build=missing + $ git clone https://github.com/conan-io/examples.git + $ cd features/multi_config + $ conan create . user/channel -Creating a multi-configuration Debug/Release package is simple, see the following example -using CMake. +Creating a multi-configuration debug/release package is simple -The first step will be to remove ``build_type`` from the settings. It will not be an input setting, the -generated package will always be the same, containing both Debug and Release artifacts. -The Visual Studio runtime is different for debug and release (``MDd`` or ``MD``) and is set using the default runtime (MD/MDd). If this meets your needs, we recommend removing the ``runtime`` subsetting in the -``configure()`` method: +The first step will be to remove ``build_type`` from the settings. It will not be an input setting and the generated package will always +contain both debug and release artifacts. +The Visual Studio runtime is different for debug and release (``MDd`` or ``MD``) and is set using the default runtime (``MD``/``MDd``). If +this meets your needs, we recommend removing the ``compiler.runtime`` subsetting in the ``configure()`` method: .. code-block:: python - class Pkg(ConanFile): + class HelloConan(ConanFile): # build_type has been omitted. It is not an input setting. settings = "os", "compiler", "arch" + generators = "cmake" + # Remove runtime and use always default (MD/MDd) def configure(self): - # it is also necessary to remove the VS runtime if self.settings.compiler == "Visual Studio": del self.settings.compiler.runtime def build(self): - cmake = CMake(self) - if cmake.is_multi_configuration: - cmmd = 'cmake "%s" %s' % (self.source_folder, cmake.command_line) - self.run(cmmd) - self.run("cmake --build . --config Debug") - self.run("cmake --build . --config Release") - else: - for config in ("Debug", "Release"): - self.output.info("Building %s" % config) - self.run('cmake "%s" %s -DCMAKE_BUILD_TYPE=%s' - % (self.source_folder, cmake.command_line, config)) - self.run("cmake --build .") - shutil.rmtree("CMakeFiles") - os.remove("CMakeCache.txt") - -In this case, we assume that the binaries will be differentiated with a suffix in the Cmake -syntax: + cmake_release = CMake(self, build_type="Debug") + cmake_release.configure() + cmake_release.build() + + cmake_debug = CMake(self, build_type="Release") + cmake_debug.configure() + cmake_debug.build() + +In this example, the binaries will be differentiated with a suffix in the CMake syntax, so we have to add this information to the data provided to the consumers in the `package_info` function: .. code-block:: cmake @@ -154,7 +142,7 @@ Such a package can define its information for consumers as: self.cpp_info.release.libs = ["mylibrary"] self.cpp_info.debug.libs = ["mylibrary_d"] -This will translate to the cmake variables: +This will translate to the CMake variables: .. code-block:: cmake @@ -164,33 +152,28 @@ This will translate to the cmake variables: set(CONAN_LIBS_DEBUG mylibrary_d ${CONAN_LIBS_DEBUG}) set(CONAN_LIBS_RELEASE mylibrary ${CONAN_LIBS_RELEASE}) -And these variables will be correctly applied to each configuration by ``conan_basic_setup()`` -helper. +And these variables will be correctly applied to each configuration by ``conan_basic_setup()`` helper. -In this case you can still use the general and not config-specific variables. For example, the include -directory when set by default to *include* remains the same for both debug and release. Those general -variables will be applied to all configurations. +In this case you can still use the general and not config-specific variables. For example, the include directory when set by default to +*include* remains the same for both debug and release. Those general variables will be applied to all configurations. .. important:: - The above code assumes that the package will always use the default Visual Studio runtime (MD/MDd). + The above code assumes that the package will always use the default Visual Studio runtime (``MD``/``MDd``). To keep the package configurable for supporting static(MT)/dynamic(MD) linking with the VS runtime - library, do the following: + library, you can do the following: - - Keep the ``compiler.runtime`` setting, i.e. do not implement the ``configure()`` method removing it. - - Don't let the CMake helper define the ``CONAN_LINK_RUNTIME`` env-var to define the runtime, because - defining it by the consumer will cause it to be incorrectly applied to both the Debug and Release artifacts. - This can be done with a ``cmake.command_line.replace("CONAN_LINK_RUNTIME", "CONAN_LINK_RUNTIME_MULTI")`` - to define a new variable. + - Keep the ``compiler.runtime`` setting, e.g. do not implement the ``configure()`` method removing it. + - Don't let the CMake helper define the ``CONAN_LINK_RUNTIME`` variable to define the runtime and define ``CONAN_LINK_RUNTIME_MULTI`` + instead. + - In *CMakeLists.txt*, use the ``CONAN_LINK_RUNTIME_MULTI`` variable to correctly setup up the runtime for debug and release flags. - Write a separate ``package_id()`` methods for MD/MDd and for MT/MTd defining the packages to be built. - - In *CMakeLists.txt*, use the ``CONAN_LINK_RUNTIME_MULTI`` variable to correctly setup up the runtime for - debug and release flags. - All these steps are already coded in the repo https://github.com/memsharded/hello_multi_config and commented - out as **"Alternative 2"** + All these steps are already coded in the repo https://github.com/conan-io/examples/tree/master/features/multi_config and commented + out as **"Alternative 2"**. -Also, you can use any custom configuration as they are not restricted. For example, if -your package is a multi-library package, you could try doing something like: +Also, you can use any custom configuration as they are not restricted. For example, if your package is a multi-library package, you could +try to do something like: .. code-block:: python @@ -198,28 +181,25 @@ your package is a multi-library package, you could try doing something like: self.cpp_info.regex.libs = ["myregexlib1", "myregexlib2"] self.cpp_info.filesystem.libs = ["myfilesystemlib"] -These specific config variables will not be automatically applied, but you can directly use them -in your consumer CMake build script. +These specific config variables will not be automatically applied, but you can directly use them in your consumer CMake build script. .. note:: - The automatic conversion of multi-config variables to generators is currently only implemented - in the ``cmake`` and ``txt`` generators. If you want to have support for them in another - build system, please open a GitHub issue. + The automatic conversion of multi-config variables to generators is currently only implemented in the ``cmake``, ``visual_studio`` and ``txt`` generators. + If you want to have support for them in another build system, please open a GitHub issue. N configs (1 build) -> N packages --------------------------------- It’s possible that an existing build script is simultaneously building binaries for different configurations, like debug/release, or different architectures (32/64bits), or library types -(shared/static). If such a build script is used in the previous “Single configuration packages” -approach, it will definitely work without problems. However, we’ll be wasting precious build time, as -we’ll be re-building the rebuilding project for each package, then extracting the relevant artifacts for +(shared/static). If such a build script is used in the previous "Single configuration packages" +approach, it will definitely work without problems. However, we'll be wasting precious build time, as +we'll be rebuilding the project for each package, then extracting the relevant artifacts for the relevant configuration, while ignoring the others. It is more efficient to build the logic, whereby the same build can be reused to create different packages: - .. image:: /images/build_once.png :height: 300 px :width: 400 px diff --git a/deploy_gh_pages.py b/deploy_gh_pages.py index d3237acadb06..cd128266f0e8 100644 --- a/deploy_gh_pages.py +++ b/deploy_gh_pages.py @@ -3,6 +3,8 @@ import shutil import tempfile +from _elastic.indexer import ElasticManager + def copytree(src, dst, symlinks=False, ignore=None): for item in os.listdir(src): @@ -36,14 +38,20 @@ def clean_gh_pages(): shutil.rmtree("en") -def build_and_copy(branch, folder_name, versions_available, validate_links=False): +def build_and_copy(branch, folder_name, versions_available, themes_dir, validate_links=False): + call("git checkout %s" % branch) call("git pull origin %s" % branch) with open('versions.json', 'w') as f: f.write(json.dumps(versions_available)) + shutil.rmtree("_themes") + copytree(themes_dir, "_themes") + call("make html") + call("make json") + if validate_links: call("make spelling") call("make linkcheck") @@ -52,9 +60,16 @@ def build_and_copy(branch, folder_name, versions_available, validate_links=False copytree("_build/html/", tmp_dir) shutil.copy2("_build/latex/conan.pdf", tmp_dir) + + tmp_dir_json = tempfile.mkdtemp() + copytree("_build/json/", tmp_dir_json) + shutil.rmtree("_build") # Go to deploy branch, copy new files and commit + call("git stash") + call("git stash drop || true") + call("git clean -d -f") call("git checkout gh-pages") if not os.path.exists("en"): os.mkdir("en") @@ -72,6 +87,8 @@ def build_and_copy(branch, folder_name, versions_available, validate_links=False call("git add -A .") call("git commit --message 'committed version %s'" % folder_name, ignore_error=True) + return tmp_dir_json + def should_deploy(): if not os.getenv("TRAVIS_BRANCH", None) == "master": @@ -97,9 +114,20 @@ def deploy(): if __name__ == "__main__": if should_deploy(): - config_git() + + # Copy the _themes to be able to share them between old versions + themes_dir = tempfile.mkdtemp() + copytree("_themes", themes_dir) + + host = os.getenv("ELASTIC_SEARCH_HOST") + region = os.getenv("ELASTIC_SEARCH_REGION") + es = ElasticManager(host, region) + es.ping() + + # config_git() clean_gh_pages() - versions_dict = {"master": "1.15", + versions_dict = {"master": "1.16", + "release/1.15.2": "1.15", "release/1.14.5": "1.14", "release/1.13.3": "1.13", "release/1.12.3": "1.12", @@ -112,11 +140,29 @@ def deploy(): "release/1.5.2": "1.5", "release/1.4.5": "1.4", "release/1.3.3": "1.3"} + + to_index = {} for branch, folder_name in versions_dict.items(): - build_and_copy(branch, folder_name, versions_dict, validate_links=branch == "master") + json_folder = build_and_copy(branch, folder_name, versions_dict, themes_dir, + validate_links=branch == "master") + to_index[folder_name] = json_folder + + # Index + print("Indexing...") + print(to_index) + + try: + es.remove_index() + except: + pass + es.create_index() + for version, folder in to_index.items(): + es.index(version, folder) deploy() + else: call("make html") + call("make json") call("make spelling") call("make linkcheck") diff --git a/developing_packages/editable_packages.rst b/developing_packages/editable_packages.rst index c687a4f18094..58870dee94f8 100644 --- a/developing_packages/editable_packages.rst +++ b/developing_packages/editable_packages.rst @@ -7,10 +7,10 @@ Packages in editable mode This is an **experimental** feature subject to breaking changes in future releases. -When working in big projects with several functionalities interconnected it is recomended to avoid -the one-and-only huge project approach in favor of several libraries each one of them specialized +When working in big projects with several functionalities interconnected it is recommended to avoid +the one-and-only huge project approach in favor of several libraries, each one specialized in a set of common tasks, even maintained by dedicated teams. This approach helps to isolate -and reuse code, helps with compiling times and reduces the likelihood of including files that +and reusing code helps with compiling times and reduces the likelihood of including files that not correspond to the API of the required library. Nevertheless, in some case, it is useful to work in several libraries at the same time and see how @@ -21,16 +21,14 @@ get the changes ready for a consumer library, it is needed the :command:`conan c actually trigger a build to generate the binaries in the cache or to run :command:`conan export-pkg` to copy locally built artifacts into the conan cache and make them available to consumers. -What about if you just can tell Conan where to find the headers and the artifacts ready for -consumption in your local working directory? No need to package, just tell Conan to use those -artifacts you have just generated with your IDE, sounds good? This is what the feature -*editable packages* will do for you. +With the editable packages, you can tell Conan where to find the headers and the artifacts ready for +consumption in your local working directory. There is no need to package. Let's see this feature over an example where a developer is creating a ``CoolApp`` but at the same -time they wants to work on ``cool/version@user/dev`` library which is tightly coupled to the app. +time they want to work on ``cool/version@user/dev`` library which is tightly coupled to the app. The package ``cool/version@user/dev`` is already working, the developer has the sources in a -local folder, they is using whatever method to build and develop locally and can perform +local folder and they are using whatever method to build and develop locally and can perform a :command:`conan create . cool/version@user/dev` to create the package. Also, there is a *conanfile.txt* (or a more complex recipe) for the application ``CoolApp`` that @@ -47,14 +45,14 @@ working directory**: .. code-block:: bash $ conan editable add cool/version@user/dev - # you could do cd && conan editable add . cool/version@user/dev + # you could do "cd && conan editable add . cool/version@user/dev" -That is it. Now, every usage of ``cool/version@user/dev``, by any other Conan package, or project -will be redirected to the ```` user folder, instead of using the package +That is it. Now, every usage of ``cool/version@user/dev``, by any other Conan package or project, +will be redirected to the ```` user folder instead of using the package from the conan cache. -Conan package recipes define a package "layout" in their ``package_info()`` methods. The default one, +The Conan package recipes define a package "layout" in their ``package_info()`` methods. The default one, if nothing is specified is equivalent to: .. code-block:: python diff --git a/getting_started.rst b/getting_started.rst index 75653ff41b6e..dfce031d58b7 100644 --- a/getting_started.rst +++ b/getting_started.rst @@ -377,14 +377,15 @@ For example, if we have a profile with a 32-bit GCC configuration in a profile c We strongly recommend using :ref:`profiles` and managing them with :ref:`conan_config_install`. -However, the user can always override the default profile settings in the :command:`conan install` command using the :command:`--settings` -parameter. As an exercise, try building the Encrypter project 32-bit version: +However, the user can always override the profile settings in the :command:`conan install` command using the :command:`--settings` +parameter. As an exercise, try building the 32-bit version of the Encrypter project like this: .. code-block:: bash - $ conan install . --profile=gcc_x86 --settings arch=x86_64 + $ conan install . --settings arch=x86 -The above command installs a different package, using the :command:`--settings arch=x86` instead of the one of the profile used previously. +The above command installs a different package, using the :command:`--settings arch=x86` instead of the one of the default profile used +previously. To use the 32-bit binaries, you will also have to change your project build: diff --git a/gh_pages.sh b/gh_pages.sh index 9ad51361a81f..de18fef603e7 100755 --- a/gh_pages.sh +++ b/gh_pages.sh @@ -1,2 +1 @@ make html && rm -rf /tmp/docs && cp -r ./_build/html/* /tmp/docs && git checkout gh-pages && git rm -r * && cp -r /tmp/docs . && git add . && git commit -m "gh pages" - diff --git a/howtos/header_only.rst b/howtos/header_only.rst index 29fd20414203..bf515a9d943f 100644 --- a/howtos/header_only.rst +++ b/howtos/header_only.rst @@ -34,7 +34,7 @@ instead of the ``exports_sources`` fields. no need to do so because source code is not modified at all by the ``configure()`` or ``build()`` methods. - Note that this recipe has no other dependencies, settings or options. If it had any of those, it would be very convenient to add the ``package_id()`` method, to ensure that only one package with always the same ID is - create irrespective of the configurations and dependencies: + created, irrespective of the configurations and dependencies: .. code-block:: python diff --git a/integrations/build_system/cmake/cmake_generator.rst b/integrations/build_system/cmake/cmake_generator.rst index b06322f60550..0de877b35b3d 100644 --- a/integrations/build_system/cmake/cmake_generator.rst +++ b/integrations/build_system/cmake/cmake_generator.rst @@ -2,7 +2,7 @@ ``cmake`` generator =================== -If you are using **CMake** to build your project, you can use the ``cmake`` generator to define all your requirements information in cmake syntax. +If you are using CMake to build your project, you can use the ``cmake`` generator to define all your requirements in CMake syntax. It creates a file named ``conanbuildinfo.cmake`` that can be imported from your ``CMakeLists.txt``. .. code-block:: text @@ -14,14 +14,15 @@ It creates a file named ``conanbuildinfo.cmake`` that can be imported from your When :command:`conan install` is executed, a file named *conanbuildinfo.cmake* is created. -You can include *conanbuildinfo.cmake* in your project's *CMakeLists.txt* to manage our requirements. -The inclusion of *conanbuildinfo.cmake* doesn't alter the CMake environment at all, it just provides ``CONAN_`` variables and some useful macros. +You can include *conanbuildinfo.cmake* in your project's *CMakeLists.txt* to manage your requirements. +The inclusion of *conanbuildinfo.cmake* doesn't alter the CMake environment at all. It simply provides ``CONAN_`` variables and some useful +macros. Global variables approach ------------------------- The simplest way to consume it would be to invoke the ``conan_basic_setup()`` macro, which will basically -set global include directories, libraries directories, definitions, etc. so typically is enough to do: +set global include directories, libraries directories, definitions, etc. so typically it is enough to call: .. code-block:: cmake @@ -31,8 +32,8 @@ set global include directories, libraries directories, definitions, etc. so typi add_executable(timer timer.cpp) target_link_libraries(timer ${CONAN_LIBS}) -The ``conan_basic_setup()`` is split in smaller macros, that should be self explanatory. If you need to do -something different, you can just use them individually. +The ``conan_basic_setup()`` is divided into smaller macros that should be self explanatory. If you need to do +something different, you can just call them individually. .. note:: @@ -57,7 +58,7 @@ For **modern cmake (>=3.1.2)**, you can use the following approach: target_link_libraries(timer CONAN_PKG::Poco) Using ``TARGETS`` as argument, ``conan_basic_setup()`` will internally call the macro ``conan_define_targets()`` -which defines cmake ``INTERFACE IMPORTED`` targets, one per package. These targets, named ``CONAN_PKG::PackageName`` can be used to link with, instead of using global cmake setup. +which defines cmake ``INTERFACE IMPORTED`` targets, one per package. These targets, named ``CONAN_PKG::PackageName`` can be used to link against, instead of using global cmake setup. .. seealso:: diff --git a/integrations/ide/visual_studio.rst b/integrations/ide/visual_studio.rst index 681e3b3d4344..ca7eaa57db02 100644 --- a/integrations/ide/visual_studio.rst +++ b/integrations/ide/visual_studio.rst @@ -1,10 +1,8 @@ .. _visual_studio: - |visual_logo| Visual Studio ___________________________ - Conan Extension for Visual Studio ================================= @@ -31,7 +29,6 @@ sources if no binaries are available). where the **Visual Studio project file** is located and then it will walk recursively into parent directories to look for them. - The extension creates a property sheet file and adds it to the project, so all the information from the dependencies handled by Conan should be added (as inherited properties) to those already available in your projects. @@ -40,13 +37,9 @@ At this moment (release ``v1.0.x``) the extension is under heavy development, so change and new features will be added. You can subscribe to `its repository`_ to stay updated and, of course, any feedback about it will be more than welcome. -.. _`its repository`: https://github.com/conan-io/conan-vs-extension - - General Integration =================== - Check the :ref:`MSBuild() integration`, that contains information about Build Helpers and generators to be used with Visual Studio. @@ -54,3 +47,5 @@ generators to be used with Visual Studio. .. |visual_logo| image:: ../../images/visual-studio-logo.png :width: 100 px :alt: Visual Studio logo + +.. _`its repository`: https://github.com/conan-io/conan-vs-extension \ No newline at end of file diff --git a/integrations/ide/youcompleteme.rst b/integrations/ide/youcompleteme.rst index cd1a0f64d4a8..6487c702cc16 100644 --- a/integrations/ide/youcompleteme.rst +++ b/integrations/ide/youcompleteme.rst @@ -3,7 +3,7 @@ YouCompleteMe (vim) ------------------- -If you are a vim user, you may also be a user of `YouCompleteMe `_. +If you are a vim user, you may also be a user of `YouCompleteMe `_. With this generator, you can create the necessary files for your project dependencies, so YouCompleteMe will show symbols from your Conan installed dependencies for your project. diff --git a/mastering/revisions.rst b/mastering/revisions.rst index 289f6a4f5278..c63babf59a06 100644 --- a/mastering/revisions.rst +++ b/mastering/revisions.rst @@ -11,8 +11,8 @@ The goal of the revisions feature is to achieve package immutability, the packag .. note:: - This is the first piece to achieve reproducibility: Recreate the exact dependency graph by using some - mechanism like a "graph lock" file. For example, if we store a "graph lock" file for the different releases + This is the first piece to achieve reproducibility: recreate the exact dependency graph by using some + mechanism like a ``graph lock`` file. For example, if we store a ``graph lock`` file for the different releases of our project, we can install the same dependencies just by using the graph lock. **IMPORTANT:** The reproducibility is in the Conan roadmap and currently under development. @@ -35,11 +35,11 @@ How it works The same package ID (for example for Linux/GCC5/Debug), can have multiple revisions (PREVs) that belong to a concrete RREV. -If a client requests a reference like ``lib/1.0@conan/stable``, Conan will retrieve automatically the latest revision. -In the client cache there will be **only one revision installed at the same time**. +If a client requests a reference like ``lib/1.0@conan/stable``, Conan will automatically retrieve the latest revision. +In the client cache there is **only one revision installed simultaneously**. The revisions can be pinned when you write a reference (in the recipe requires, or in a reference in a -:command:`conan install` command...) but if you don't specify a revision the server will retrieve the latest one. +:command:`conan install` command…) but if you don’t specify a revision, the server will retrieve the latest revision. You can specify the references in the following formats: @@ -69,13 +69,13 @@ You have to explicitly activate the feature by: Take into account that it changes the default Conan behavior. e.g: - - A client with revisions enabled will only find binary packages that belongs to the installed recipe revision. + - A client with revisions enabled will only find binary packages that belong to the installed recipe revision. For example, If you create a recipe and run :command:`conan create . user/channel` and then you modify the recipe and - export it :command:`conan export . user/channel`, the binary package generated in the :command:`conan create` command doesn't - belong to the new exported recipe, so it won't be located unless the previous recipe is recovered. + export it (:command:`conan export . user/channel`), the binary package generated in the :command:`conan create` command + doesn't belong to the new exported recipe. So it won't be located unless the previous recipe is recovered. - - If you generate and upload N binary packages for a recipe revision, if you upload the revision you need to - generate and upload again the N binaries if you want them to be used with the new recipe. + - If you generate and upload N binary packages for a recipe with a given revision, then if you modify the recipe, and thus the recipe + revision, you need to build and upload N new binaries matching that new recipe revision. Server support -------------- diff --git a/reference/conanfile/attributes.rst b/reference/conanfile/attributes.rst index dcd019b376c0..7900dbaad76c 100644 --- a/reference/conanfile/attributes.rst +++ b/reference/conanfile/attributes.rst @@ -185,7 +185,7 @@ default_user, default_channel For package recipes working in the user space, with local methods like :command:`conan install .` and :command:`conan build .`, there is no current user/channel. If you are accessing to ``self.user`` or ``self.channel`` in your recipe, you need to declare the environment variables ``CONAN_USERNAME`` and ``CONAN_CHANNEL`` or you can set the attributes -``default_user`` and ``default_channel``. You can also use python ``@properties``: +``default_user`` and ``default_channel``. You can also use python ``@property``: .. code-block:: python diff --git a/reference/conanfile/methods.rst b/reference/conanfile/methods.rst index 585a6f15d0b0..7fd3387b5630 100644 --- a/reference/conanfile/methods.rst +++ b/reference/conanfile/methods.rst @@ -751,8 +751,6 @@ This is the relation of Visual Studio versions and the compatible toolchain: +-----------------------+--------------------+ | 14 | v140 | +-----------------------+--------------------+ -| 13 | v120 | -+-----------------------+--------------------+ | 12 | v120 | +-----------------------+--------------------+ | 11 | v110 | diff --git a/reference/env_vars.rst b/reference/env_vars.rst index cd3679e8cbbd..71f0c4d8cbe1 100644 --- a/reference/env_vars.rst +++ b/reference/env_vars.rst @@ -278,7 +278,7 @@ For example: .. code-block:: bash - CONAN_MAKE_PROGRAM="scan-build cmake" + CONAN_CMAKE_PROGRAM="scan-build cmake" CONAN_MSBUILD_VERBOSITY ----------------------- diff --git a/reference/generators/cmake.rst b/reference/generators/cmake.rst index 929d3f8270b3..72098029b0e1 100644 --- a/reference/generators/cmake.rst +++ b/reference/generators/cmake.rst @@ -159,55 +159,59 @@ These targets are: - Each ``CONAN_LIB`` depends on the direct public dependencies ``CONAN_PKG`` targets of its container package. This guarantees correct link order. +.. _conan_check_compiler: + conan_check_compiler() ++++++++++++++++++++++ Checks that your compiler matches the one declared in settings. +This method can be disabled setting the :ref:`conan_disable_check_compiler` variable. + conan_output_dirs_setup() +++++++++++++++++++++++++ -Adjust the *bin/* and *lib/* output directories. +Adjusts the *bin/* and *lib/* output directories. conan_set_find_library_paths() ++++++++++++++++++++++++++++++ -Set ``CMAKE_INCLUDE_PATH`` and ``CMAKE_INCLUDE_PATH``. +Sets ``CMAKE_INCLUDE_PATH`` and ``CMAKE_INCLUDE_PATH``. conan_global_flags() ++++++++++++++++++++ -Set the corresponding variables to CMake's ``include_directories()`` and ``link_directories()``. +Sets the corresponding variables to CMake's ``include_directories()`` and ``link_directories()``. conan_define_targets() ++++++++++++++++++++++ -Define the targets for each dependency (target flags instead of global flags). +Defines the targets for each dependency (target flags instead of global flags). conan_set_rpath() +++++++++++++++++ -Set ``CMAKE_SKIP_RPATH=1`` in the case of working in OSX. +Sets ``CMAKE_SKIP_RPATH=1`` in the case of working in OSX. conan_set_vs_runtime() ++++++++++++++++++++++ -Adjust the runtime flags ``/MD``, ``/MDd``, ``/MT`` or ``/MTd`` for Visual Studio. +Adjusts the runtime flags ``/MD``, ``/MDd``, ``/MT`` or ``/MTd`` for Visual Studio. conan_set_std() +++++++++++++++ -Set ``CMAKE_CXX_STANDARD`` and ``CMAKE_CXX_EXTENSIONS`` to the appropriate values. +Sets ``CMAKE_CXX_STANDARD`` and ``CMAKE_CXX_EXTENSIONS`` to the appropriate values. conan_set_libcxx() ++++++++++++++++++ -Adjust the standard library flags (``libc++```, ``libstdc++``, ``libstdc++11``) in ``CMAKE_CXX_FLAGS``. +Adjusts the standard library flags (``libc++```, ``libstdc++``, ``libstdc++11``) in ``CMAKE_CXX_FLAGS``. conan_set_find_paths() ++++++++++++++++++++++ -Adjust ``CMAKE_MODULE_PATH`` and ``CMAKE_PREFIX_PATH`` to the values of ``deps_cpp_info.build_paths``. +Adjusts ``CMAKE_MODULE_PATH`` and ``CMAKE_PREFIX_PATH`` to the values of ``deps_cpp_info.build_paths``. Input variables for *conanbuildinfo.cmake* ------------------------------------------ @@ -218,3 +222,12 @@ CONAN_CMAKE_SILENT_OUTPUT **Default to**: ``FALSE`` Activate it to silence the Conan message output. + +.. _conan_disable_check_compiler: + +CONAN_DISABLE_CHECK_COMPILER +++++++++++++++++++++++++++++ + +**Default to**: ``FALSE`` + +Deactivates the check of the compiler done with the method :ref:`conan_check_compiler`. diff --git a/reference/generators/qmake.rst b/reference/generators/qmake.rst index 9c00725b101b..17e152c8a24c 100644 --- a/reference/generators/qmake.rst +++ b/reference/generators/qmake.rst @@ -9,7 +9,7 @@ qmake Go to :ref:`Integrations/Qmake` if you want to learn how to integrate your project or recipes with qmake. -Generates a file named ``conanbuildinfo.pri`` that can be used for your qbs builds. +Generates a file named ``conanbuildinfo.pri`` that can be used for your qmake builds. The file contains: - N groups of variables, one group per require, declaring the same individual values: include_paths, libs, bin dirs, libraries, defines etc. diff --git a/reference/profiles.rst b/reference/profiles.rst index 70e0596b4c67..1b60399519c7 100644 --- a/reference/profiles.rst +++ b/reference/profiles.rst @@ -22,6 +22,12 @@ requirements** in a file. They have this structure: Tool2/0.1@user/channel, Tool3/0.1@user/channel *: Tool4/0.1@user/channel +Profile can be created with ``new`` option in :command:`conan profile`. And then edit it later. + +.. code-block:: bash + + $ conan profile new mynewprofile --detect + Profile files can be used with ``-pr``/``--profile`` option in :command:`conan install` and :command:`conan create` commands. .. code-block:: bash diff --git a/replace_analytics_code.py b/replace_analytics_code.py new file mode 100644 index 000000000000..bf5d95f178f5 --- /dev/null +++ b/replace_analytics_code.py @@ -0,0 +1,26 @@ +import os +import subprocess + +lines = subprocess.check_output(['git', 'branch', "-a"]).decode().split("\n") + +branches = [] +for line in lines: + line = line.strip() + if line.startswith("remotes/origin/release/"): + branches.append(line.split("remotes/origin/")[1]) + +old_code = "UA-68594724-3" +old_code_2 = "GTM-53TFLK7" +new_code = "GTM-WK44ZFM" + +if __name__ == "__main__": + + for br in branches: + os.system("git checkout {}".format(br)) + command = "find ./ -type f | grep -v .git | xargs sed -i 's/{}/{}/g'\\;".format(old_code, new_code) + print(command) + os.system(command) + os.system("find ./ -type f | grep -v .git | xargs sed -i 's/{}/{}/g'\\;".format(old_code_2, new_code)) + os.system("git add .") + os.system("git commit -m \"Replaced old GA code\"") + os.system("git push origin {}".format(br)) diff --git a/requirements.txt b/requirements.txt index 333a013be6d5..213df2cfb8dd 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,2 +1,6 @@ sphinx==1.7.9 sphinxcontrib-spelling +elasticsearch>=6.0.0,<7.0.0 +boto3 +requests +requests-aws4auth \ No newline at end of file