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

[feature] Better management of fPIC #12121

Closed
memsharded opened this issue Sep 15, 2022 · 3 comments
Closed

[feature] Better management of fPIC #12121

memsharded opened this issue Sep 15, 2022 · 3 comments
Milestone

Comments

@memsharded
Copy link
Member

Now things in our template works relatively well, because the default is fPIC=True, for static and shared libraries.

If some users default it to False, then it will be a bit inconvenient, because it is necessary to:

  • Put the fPIC=True for shared=True (besides setting the shared=True, because otherwise for example https://cmake.org/cmake/help/latest/prop_tgt/POSITION_INDEPENDENT_CODE.html#prop_tgt:POSITION_INDEPENDENT_CODE, that default invalidates the CMake one, and will error, which is a different behavior than not defining fPIC at all
  • Put all the static libraries transitive dependencies to fPIC=True, which might be difficult to handle, specially if we don't want to just put everything in the graph as fPIC=True. It seems that a recipe should do something in the line of:
def configure(self):
     if self.options.shared:
             self.options[*":fPIC"] = True

Something similar happens if we want, leaving the fPIC=True default, to change to False those that are static libraries not reused by shared ones, it would be quite challenging to do it from the consumer side.

Is it maybe something to propagate automatically like a trait?

@lasote lasote added this to the 1.53 milestone Sep 15, 2022
@lasote
Copy link
Contributor

lasote commented Sep 15, 2022

Something similar happens if we want, leaving the fPIC=True default, to change to False those that are static libraries not reused by shared ones, it would be quite challenging to do it from the consumer side.

Is it maybe something to propagate automatically like a trait?

I don't see it as a trait but maybe in a similar case, we talked about the language attribute that would remove libcxx and cppstd when C. Maybe the configure should have by default a "smart" adjustment based on the shared of transitive dependencies and reading the shared option of the recipe itself.

@czoido czoido modified the milestones: 1.53, 1.54 Oct 4, 2022
@memsharded memsharded modified the milestones: 1.54, 1.55 Nov 2, 2022
@memsharded
Copy link
Member Author

Too much and too new for current moment, moving it to 2.X

@memsharded
Copy link
Member Author

This was addressed with the new implements attribute in Conan 2.0.9 (#14320), closing as solved, see https://docs.conan.io/2/changelog.html#jul-2023

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

No branches or pull requests

3 participants