On Thu, Mar 10, 2011 at 10:02 UTC, Jef Driesen <jefdrie...@hotmail.com> wrote: > I'm aware of the advantage of using pkg-config. I even supply the *.pc > files for my own projects. But the point is that if I want to support systems > that don't have pkg-config installed (like Mac OS X in my case), I have to > provide a fallback with manual detection anyway.
But you are not everyone. In some cases, the use of the library is optional, or there is a bundled copy of the library used when an installed one isn't found via pkg-config. It's reasonable to provide no fallback probing for an installed headers and libs -- you just proceed without or substitute. > So why not skip pkg-config entirely? Personally, I want to never write any more manual detection code when pkg-config will do the job. I'm also a big fan of the way PKG_CONFIG_PATH lets me customize my choices as a user of a system which is shared with and administered by others. The staff likes a 6 year old version of openssl with backported patches as of three years ago, which triggers compiler warnings that modern openssl headers don't? I love that I can install a newer openssl in my homedir and arrange my PKG_CONFIG_PATH to find my openssl before the decrepit one, for packages that respect any openssl.pc found via pkg-config. I could get by without pkg-config, but it would mean specifying extra configure options repeatedly to point to my local openssl. pkg-config lets me enshrine that preference once and get on with more important things than remember which combination of overrides I need at configure time. Cheers, Dave Hart
