xcodedeps: provide package root dir

[the-nic]

Changelog: Feature: Defines the PACKAGE_ROOT_<package> variable in XcodeDeps generated files.
Docs: conan-io/docs#2717

If one wants to access other folders than the provided ones (like
resources), the provided variables dont contain enough information
to access these folders.

Provide a new variable, PACKAGE_ROOT_<package>_<component> pointing
to the root directory of the package allowing to use it within xcode.

We have to pass the package folder as another parameter, because the
transitive_cpp_info variable does not contain the rootpath
attribute and we also cant access the package_folder attribute from
self._conanfile.dependencies.package_folder directly because
the package name is already formatted via _format_name.

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

^{Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.}

[czoido]

Hi @the-nic,

Thanks for the contribution.

I think that maybe it would be better to use the resdirs information from the cppinfo so that if a package have a directory for resources it is available. And a variable something like RESOURCE_PATHS_libname_libname[...][...][...] = ...

Is there a case where you need to access directly the package folder that is not covered by the case that you add the resdir to the cppinfo and have access to it?

[the-nic]

I think that maybe it would be better to use the resdirs information from the cppinfo so that if a package have a directory for resources it is available. And a variable something like RESOURCE_PATHS_libname_libname[...][...][...] = ...

Certainly, this would be a good addition, too.

Is there a case where you need to access directly the package folder that is not covered by the case that you add the resdir to the cppinfo and have access to it?

The problem is, these are often multiple paths and if I have to reference a specific file from the package, it its impossible to do without the single root path. Additionally, the cmake generator also provides a package root path, so they become a bit more on par.

[czoido]

Hi @the-nic,
I was thinking that probably it would be better to define this variable in the file that includes all components for the package instead here, and not with the component suffix but just as: PACKAGE_ROOT_<package> because that information will be the same for all the components. WDYT?

[the-nic]

Hi @the-nic, I was thinking that probably it would be better to define this variable in the file that includes all components for the package instead here, and not with the component suffix but just as: PACKAGE_ROOT_<package> because that information will be the same for all the components. WDYT?

Good point, I'll update the PR

[the-nic]

Hi @czoido I tried your suggestion right now and the problem is that the even though the information is the same for all components, its not the same for all configurations. And only the component files seem to be configuration-aware. Otherwise, we'd have to update the package file on each time a new configuration is added...

[czoido]

Hi @the-nic,
Sorry, you are right, I did not take that into account. Then maybe it's better to just leave them in the components files, but remove the _{{comp_name}} and let them be defined in multiple times (I suppose it won't be a problem, but I had to test that first).

[the-nic]

@czoido I have removed the component name from the root dir variable.

[czoido]

Thanks a lot @the-nic,
I'll do some checks and then I think it's good to merge.
Maybe in the future if we add more variables at package level it would be worth to make a separate file that defines them all and that is included from the file that includes the components, but if the multiple definition is not a problem I think this is good enough for the moment.
Thanks!