Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document CppInfo components and new attributes #1363

Merged
merged 10 commits into from Mar 25, 2020

Conversation

danimtb
Copy link
Member

@danimtb danimtb commented Jul 11, 2019

Copy link
Contributor

@lasote lasote left a comment

I miss three ideas to be transmitted in the components section:

  1. When you are creating a Conan package it is recommended to package only 1 library file (lib, a, so, dll...), but sometimes, especially with third-party projects like Boost, Poco or even OpenSSL, they contain several libraries inside.
  2. Then it is sometimes necessary to model relations between the libraries of the same Conan package. Typically a library will be a component so if a library depends on another in the same package, you can declare the dependence relationship. The consumer will receive the correct linking order.
  3. It will allow (NOT IMPLEMENTED YET) to the generators to be more advance in the future. Some examples:
    • The CMake find_package scripts could allow working with COMPONENTS.
    • The name field declared could determine the name of the xxx-config.cmake file or the name of the xxx.pc file for pkg-config and so on.

lasote
lasote approved these changes Jul 25, 2019
@lasote lasote removed this from the 1.18 milestone Jul 30, 2019
@lasote lasote added this to the 1.19 milestone Jul 30, 2019
@lasote lasote removed this from the 1.19 milestone Aug 20, 2019
@danimtb danimtb added this to the 1.24 milestone Mar 23, 2020
granularity when linking with packages with more than one library packaged.
- Generate files with appropriate names for CMake config and package config files like: *xxx-config.cmake* or *xxx.pc*

The structure of the ``Component`` object is the same as the one used by the ``cpp_info`` object and has **the same default directories**.
Copy link
Member

@memsharded memsharded Mar 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 important notes are needed here:

  • That no global definition is possible if you are using components
  • That the feature so far is not fully implemented, and at the moment is is only the definition in the conanfile, but is transparent and has no effect on consumers at all, and that is ongoing work.


The paths of the directories in the directory variables indicated above are relative to the
:ref:`self.package_folder<folders_attributes_reference>` directory.

.. _cpp_info_components_attributes_reference:

Components
Copy link
Member

@memsharded memsharded Mar 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I would prefer the reference the other way round:

  • The attribute is only a placeholder, with a link
  • The package_info() method is the section of the docs that contains all the detailed information about cpp_info and components.

Not to be changed now, but to have the idea in mind for the future.

Copy link
Member Author

@danimtb danimtb Mar 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, will take this into account for next refactors of the documentation


- Generate different targets with appropriate names in CMake to iterate better with ``find_package()`` functionality. This will allow more
granularity when linking with packages with more than one library packaged.
- Generate files with appropriate names for CMake config and package config files like: *xxx-config.cmake* or *xxx.pc*
Copy link
Member

@jgsogo jgsogo Mar 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is something we should mention. Probably all components should go in the same file (is it not possible for any generator?). If the components generate their own file, we can have collisions and Conan won't be able to handle them.

And, as this is totally speculative, I would vote to remove this example

Copy link
Member Author

@danimtb danimtb Mar 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right. This was here when the feature was introduced together with the cpp_info.name attribute. But I think it is better to remove this from the reference right now and explain it better in a dedicated section in the future. Thanks!

Copy link
Member

@memsharded memsharded Mar 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, please remove that.

@memsharded memsharded assigned jgsogo and unassigned memsharded Mar 24, 2020
@@ -970,6 +1016,10 @@ root folder of the package:
# Get the sharedlinkflags property from OpenSSL package
self.deps_cpp_info["openssl"].sharedlinkflags

.. seealso::

Read more about :ref:`cpp_info_components_attributes_reference` in ``self.cpp_info``.
Copy link
Member

@jgsogo jgsogo Mar 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is linking to this same section 🤔 Probably we can remove this seealso section, right?

Copy link
Member Author

@danimtb danimtb Mar 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you are right

jgsogo
jgsogo approved these changes Mar 25, 2020
@jgsogo jgsogo merged commit 10beab1 into conan-io:develop Mar 25, 2020
2 checks passed
@fulara
Copy link

@fulara fulara commented Aug 2, 2020

These docs dont explain at all how to use these paths in the consuming recipes, they are very arbitraty.

The documentation states:

    def build(self):
        # Get the include directories of the SSL component of openssl package
        self.deps_cpp_info["openssl"].components["ssl"].include_paths

And it does not link to anything anywhere how to propagate these in cmake or any generator.
I tried searching by lib_paths include_paths but to my knowledge there is no such documentation.

Can we get some real example somewhere please?

comment really to the work itself:
On top of that even though the package offers consumers if in the clients package someone uses CONAN_PKG::providing_pkg
they will depend on all of those

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants