[feature] Allow different cpp_info.name depending on the generator
See original GitHub issueSomething similar to self.cpp_info.name['my_generator']
should work.
Make it compatible with cpp_info.name = 'name'
syntax
Related to #5984
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Attributes — conan 1.53.0 documentation
Using components and global cpp_info non-default values or release/debug configurations at the same time is not allowed (except for self.cpp_info.names ).
Read more >conan/CHANGELOG and conan Releases (Page 3) | LibHunt
Bugfix: Fix pkg_config generator adding to .pc files empty include and lib ... Docs:; Feature: Allow conan.conf user configuration of paths to client ......
Read more >cpp.texi - Apple Open Source
This feature allows you to break long lines for cosmetic purposes without changing their meaning. @item Predefined macro names are replaced with their ......
Read more >conan Changelog - pyup.io
Feature : Do not allow doing conan create/export with uncommitted changes ... of packages that are equivalent with different names for different distros....
Read more >Error installing Pystan in python 3.10 with gcc 9.2.0
Compiling pystan/_chains.pyx because it depends on /home/user/py310/lib/python3.10/site-packages/Cython/Includes/libcpp/vector.pxd.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
To simplify the implementation we propose to keep the
name
and introducenames
as the dict for the generators. Otherwise, getting thestr
from thecppinfo.name
it is very problematic and requires ugly code. Thenames
is much more pragmatic.@ledocc Managing internal details within a package would be part of the
components
feature. There was a PR open for this, but it was a bit risky and was put on hold at the moment. We would eventually resume work on thecomponents
feature, but not a priority at the moment.