From f8cd5033e5afae308acd6442e58ed7ca2eec4234 Mon Sep 17 00:00:00 2001 From: Daniel Date: Fri, 20 Mar 2020 13:48:41 +0100 Subject: [PATCH] Update output of the hello library (#1614) --- creating_packages/getting_started.rst | 4 +-- creating_packages/package_repo.rst | 7 ++--- developing_packages/package_dev_flow.rst | 6 ++-- devtools/running_packages.rst | 35 +++++++++++++----------- howtos/custom_generators.rst | 6 ++-- 5 files changed, 30 insertions(+), 28 deletions(-) diff --git a/creating_packages/getting_started.rst b/creating_packages/getting_started.rst index c73adfcbdab..1ba7b27e37a 100644 --- a/creating_packages/getting_started.rst +++ b/creating_packages/getting_started.rst @@ -214,9 +214,9 @@ You can create and test the package with our default settings simply by running: $ conan create . demo/testing ... - Hello world! + Hello world Release! -If "Hello world!" is displayed, it worked. +If "Hello world Release!" is displayed, it worked. The :command:`conan create` command does the following: diff --git a/creating_packages/package_repo.rst b/creating_packages/package_repo.rst index a8d7f4d2531..1e597c63377 100644 --- a/creating_packages/package_repo.rst +++ b/creating_packages/package_repo.rst @@ -92,7 +92,7 @@ And simply create the package for user and channel **demo/testing** as described $ conan create . demo/testing ... Hello/0.1@demo/testing test package: Running test() - Hello world! + Hello world Release! .. _scm_feature: @@ -114,13 +114,13 @@ remote and commit of the local repository: from conans import ConanFile, CMake, tools class HelloConan(ConanFile): - scm = { + scm = { "type": "git", # Use "type": "svn", if local repo is managed using SVN "subfolder": "hello", "url": "auto", "revision": "auto", "password": os.environ.get("SECRET", None) - } + } ... You can commit and push the *conanfile.py* to your origin repository, which will always preserve the ``auto`` @@ -206,4 +206,3 @@ be valid too: and by default, the :command:`conan upload` will block the upload of the recipe. This prevents recipes to be uploaded with incorrect scm values exported. You can use :command:`conan upload --force` to force uploading the recipe with the "auto" values un-replaced. - diff --git a/developing_packages/package_dev_flow.rst b/developing_packages/package_dev_flow.rst index 9434aed4361..8f5817ee596 100644 --- a/developing_packages/package_dev_flow.rst +++ b/developing_packages/package_dev_flow.rst @@ -206,8 +206,8 @@ As a summary, you could use the default folders and the flow would be as simple .. code-block:: bash - $ git clone git@github.com:memsharded/example_conan_flow.git - $ cd example_conan_flow + $ git clone https://github.com/conan-io/examples.git + $ cd features/package_development_flow $ conan source . $ conan install . -pr=default $ conan build . @@ -218,7 +218,7 @@ As a summary, you could use the default folders and the flow would be as simple $ conan test test_package Hello/1.1@user/testing ... Hello/1.1@user/testing (test package): Running test() - Hello World! + Hello World Release! conan create ^^^^^^^^^^^^ diff --git a/devtools/running_packages.rst b/devtools/running_packages.rst index 8e72cdff4fb..5de8fb66786 100644 --- a/devtools/running_packages.rst +++ b/devtools/running_packages.rst @@ -65,15 +65,16 @@ This will generate a few files that can be called to activate and deactivate the $ activate_run.sh # $ source activate_run.sh in Unix/Linux $ greet - > Hello World! + > Hello World Release! $ deactivate_run.sh # $ source deactivate_run.sh in Unix/Linux Imports ------- -It is possible to define a custom conanfile (either .txt or .py), with an ``imports`` section, that can retrieve from local +It is possible to define a custom conanfile (either *.txt* or *.py*), with an ``imports()`` section, that can retrieve from local cache the desired files. This approach requires a user conanfile. -For more details see example below :ref:`runtime packages` + +For more details see the example below :ref:`runtime packages`. Deployable packages ------------------- @@ -100,7 +101,7 @@ With that method in our package recipe, it will copy the executable when install ... > Hello/0.1@user/testing deploy(): Copied 1 '.exe' files: greet.exe $ bin\greet.exe - > Hello World! + > Hello World Release! The deploy will create a *deploy_manifest.txt* file with the files that have been deployed. @@ -121,7 +122,9 @@ with: Using the `deploy` generator ---------------------------- -The :ref:`deploy generator ` is used to have all the dependencies of an application copied into a single place. Then all the files can be repackaged into the distribution format of choice. +The :ref:`deploy generator ` is used to have all the dependencies of an application copied into a single place. Then all +the files can be repackaged into the distribution format of choice. + For instance, if the application depends on boost, we may not know that it also requires many other 3rt-party libraries, such as `zlib `_, @@ -141,14 +144,16 @@ This helps to collect all the dependencies into a single place, moving them out Using the `json` generator -------------------------- -A more advanced approach is to use the :ref:`json generator `: -This generator works in a similar fashion as the `deploy` one, although it doesn't copy the files to a directory. Instead, it generates a JSON file with all the information about the dependencies including the location of the files in the Conan cache. +A more advanced approach is to use the :ref:`json generator `. This generator works in a similar fashion as the +`deploy` one, although it doesn't copy the files to a directory. Instead, it generates a JSON file with all the information about the +dependencies including the location of the files in the Conan cache. .. code-block:: bash $ conan install . -g json -The *conanbuildinfo.json* file produced is fully machine-readable and could be used by scripts to prepare the files and recreate the appropriate format for distribution. The following code shows how to read the library and binary directories from the *conanbuildinfo.json*: +The *conanbuildinfo.json* file produced, is fully machine-readable and could be used by scripts to prepare the files and recreate the +appropriate format for distribution. The following code shows how to read the library and binary directories from the *conanbuildinfo.json*: .. code-block:: python @@ -174,7 +179,9 @@ The *conanbuildinfo.json* file produced is fully machine-readable and could be u bin_dir = os.path.relpath(bin_path, root) dep_bin_dirs[bin_path] = bin_dir -While with the `deploy` generator all the files were copied into a folder, the advantage with the `json` one is that you have fine-grained control over the files and those can be directly copied to the desired layout. +While with the `deploy` generator, all the files were copied into a folder. The advantage with the `json` one is that you have fine-grained +control over the files and those can be directly copied to the desired layout. + In that sense, the script above could be easily modified to apply some sort of filtering (e.g. to copy only shared libraries, and omit any static libraries or auxiliary files such as pkg-config .pc files). @@ -203,15 +210,11 @@ Additionally, you could also write a simple startup script for your application ld_library_path=ld_library_path, exe=exe) -.. note:: - - The full example might be found on `GitHub `_. - Running from packages --------------------- If a dependency has an executable that we want to run in the conanfile, it can be done directly in code -using the ``run_environment=True`` argument. It internally uses a ``RunEnvironment()`` helper. +using the ``run_environment=True`` argument. It internally uses a ``RunEnvironment()`` helper. For example, if we want to execute the :command:`greet` app while building the ``Consumer`` package: .. code-block:: python @@ -234,7 +237,7 @@ Now run :command:`conan install` and :command:`conan build` for this consumer re $ conan install . && conan build . ... Project: Running build() - Hello World! + Hello World Release! Instead of using the environment, it is also possible to explicitly access the path of the dependencies: @@ -317,7 +320,7 @@ Installing and running this package can be done using any of the methods present # It will not install Hello/0.1@... $ activate_run.sh # $ source activate_run.sh in Unix/Linux $ greet - > Hello World! + > Hello World Release! $ deactivate_run.sh # $ source deactivate_run.sh in Unix/Linux .. _deployment_challenges: diff --git a/howtos/custom_generators.rst b/howtos/custom_generators.rst index 038fb203d0b..93f2224a79e 100644 --- a/howtos/custom_generators.rst +++ b/howtos/custom_generators.rst @@ -128,7 +128,7 @@ Put the following files inside. Note the ``PremakeGen@0.1@myuser/testing`` packa [requires] hello/0.1@myuser/testing PremakeGen@0.1@myuser/testing - + [generators] Premake @@ -136,7 +136,7 @@ Put the following files inside. Note the ``PremakeGen@0.1@myuser/testing`` packa :caption: *main.cpp* #include "hello.h" - + int main (void) { hello(); } @@ -185,7 +185,7 @@ Now we are ready to build the project: $ premake4 gmake $ make (or mingw32-make if in windows-mingw) $ ./MyApplication - Hello World! + Hello World Release! Now everything works, so you might want to share your generator: