It is common out there that buildsystems, SDKs and tools use convenience variables for these since for software development, one would need to hand-craft them in the same repetitive way. Here is the proposal for two convenience variables: PKG_CONFIG_INCLUDE_DIR=$PKG_CONFIG_SYSROOT_DIR/usr/include ... PKG_CONFIG_LIBRARY_DIR=$PKG_CONFIG_SYSROOT_DIR/usr/lib:$PKG_CONFIG_SYSROOT_DIR/lib ... The SDK environment setup script then would contain these two additional lines. For sure, it would be getting more complex if someone does not use standard paths, etc, but that is a different issue.
The SDK environment setup script is used to setup the cross development environment so these 2 variables definitlely don't belong there. Also, we've made some cleanup of the toolchain-scripts/meta-environment with this patch recently. http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta?id=d6cc7c8ed76c8b1117cf03c7bd4b0742f98f79b3
> The SDK environment setup script is used to setup the cross development environment so these 2 variables definitely don't belong there. Include and library paths are very much essentials for cross development environments. In fact, I see people hand-crafting themselves, hence the logic to do it in one place without any additional harm with a pretty easy extension. It is not accidental that the previous mentioned environments also supply these. How would you build a third-party software without include and library paths, really? I would suggest to reconsider this, or give a more thorough explanation why it makes sense. Failing that, I will just try to send a patch myself to the mailing list because I think there is something misunderstanding. Moreover, the "base" variable does not seem to be removed, but I think it would be weird to see that removed.
The problem is also that if people hand-craft it themselves, it will be more difficult for end-users to move their application from one SDK version to another. This is another reason on top of the simple convenience wrapper.