Bug 73372

Summary:	Better support for uninstalled frameworks
Product:	pkg-config	Reporter:	Michael C. Grant <mcg>
Component:	src	Assignee:	pkg-config
Status:	RESOLVED MOVED	QA Contact:
Severity:	enhancement
Priority:	medium	CC:	mcg
Version:	unspecified
Hardware:	All
OS:	Mac OS X (All)
Whiteboard:
i915 platform:		i915 features:

Description Michael C. Grant 2014-01-07 20:48:05 UTC

As you probably know, Mac OSX has the concept of "Frameworks" that encapsulates shared libraries, header files, and the like into a convenient package. Users specify a framework to be used using the "-framework <fname>" argument. If the framework is not in a standard system location, it is necessary to precede this with an additional "-F<path>" argument as well. These two argument types are analogous to "-l" and "-L" library arguments, respectively.

So you probably know where this is going, because I've seen discussion of it in earlier pkg-config mailing lists... can we better support these flags in pkg-config?

Options:
--- Include "-framework <fname>" arguments when calling "pkg-config --libs-only-l", and "-F<path>" when using "pkg-config --libs-only-L".
--- Create new options that are suited specifically for frameworks; e.g., --frameworks-only-f and --frameworks-only-F. 
--- Create--libs-only-lf and --libs-only-LF that retrieve both library and framework data simultaneously. 

The advantage of the first approach is that many packages that rely on pkg-config for library discovery will suddenly "just work" on a Mac if their dependencies are provided in framework form. For instance, Qt is provided as a framework on the Mac; and if installed via Homebrew, it does not appear in the system path. So we would like to see things like this:

LDFLAGS+=-F/usr/local/Cellar/qt/4.8.5/lib
LIBS+=-framework QtCore -framework QtGui -framework QtNetwork

The disadvantage of the first approach is that the mnemonic value of the command-line options --libs-only-l and --libs-only-L are damaged. My personal opinion is that this is outweighed by the benefits. The second and third approaches will require many existing configure scripts to be changed to add these new framework-specific calls.

I will say that a fix here goes hand in hand with a patch I have proposed for libtool (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16384). In that case, I modified libtool to treat -F in the same manner as it currently treats -L; and in doing so, I ensure that the framework paths are properly passed to the linker. Note that libtool *already* treats -framework arguments properly; it was just -F that needed fixing.

I'm willing to work on a patch here if a consensus can be reached.

Comment 1 Michael C. Grant 2014-01-07 20:59:17 UTC

Actually, here's a fourth compromise option: create a new option, say '--include-frameworks'. When used, it will include frameworks in the --libs-only-l and --libs-only-L options.

The advantage here is that many configure scripts could be "fixed" by doing something like PKG_CONFIG="pkg-config --include-frameworks".

Comment 2 Jordi Gutiérrez Hermoso 2014-01-15 20:00:57 UTC

I think we're going to have a hard time getting patches accepted to pkg-config. I have not heard good things about the maintainership of this project. We might need a workaround for -F and -f flags that does not depend on patching pkg-config.

For example, this same issue has been brought up almost six years ago without resolution:

http://lists.freedesktop.org/archives/pkg-config/2008-August/000328.html

Comment 3 Michael C. Grant 2014-01-15 20:09:35 UTC

Fair enough, Jordi. I've put together what I believe is a reasonable workaround for our case (Octave). See the bug discussion over there for the latest.

Comment 4 GitLab Migration User 2018-08-25 12:55:43 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pkg-config/pkg-config/issues/34.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.