Bug 5771

Summary:	Add convenience variables for the include and library paths
Product:	[Yocto Project Subprojects] ADT	Reporter:	Laszlo Papp <lpapp>
Component:	adt	Assignee:	Jessica <jessica.zhang>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	Undecided	CC:	bluelightning, poky.adt.watcher, poky.watcher
Version:	unspecified
Target Milestone:	---
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Yes (doc changes required)

Description Laszlo Papp 2014-01-29 18:32:00 UTC

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.

Comment 1 Jessica 2014-01-31 00:22:47 UTC

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

Comment 2 Laszlo Papp 2014-01-31 00:35:20 UTC

> 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.

Comment 3 Laszlo Papp 2014-01-31 00:43:03 UTC

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.