requirements for native gems not free text?

[Jordi Massaguer Pla]

Hi all,

when deploying gems automatically it would be great if we could
somehow know which system requirements a native gem has. I've read in
the documentation that there is the requirements field that can be
used for that purpose. However, the requirements field is "free text",
and that makes it difficult to parse with an automatic tool.

Then, I thought about sending a PR to the native gems we use so that
they have this information in a more "structred" way. For example, for
rmagick, the PR would add this to the gemspec:

s.requirements = ["libMagick.so >= 6.6.0", "pkgconfig(libMagick) >= 6.6.0"]

meaning that rmagick gem needs libMagick and libMagick-devel.

What do you think on writing the requirements in such a way? Do you
have any recomendation on that?
_______________________________________________
RubyGems-Developers mailing list
http://rubyforge.org/projects/rubygems
RubyGems-...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers

[Evan Phoenix]

This has been brought up before and we've rejected it. There is no reasonable way for rubygems to make sense of the values in requirements because their entirely system dependent.

In 2.0, gem metadata can be used to store these kinds of values for you to write a tool that will read them (which again will have to deal with the system dependent issues itself).

- Evan

--
Evan Phoenix // ev...@phx.io

> RubyGems-...@rubyforge.org (mailto:RubyGems-...@rubyforge.org)
> http://rubyforge.org/mailman/listinfo/rubygems-developers

[Jordi Massaguer Pla]

Quoting Evan Phoenix <ev...@phx.io>:

> This has been brought up before and we've rejected it. There is no
> reasonable way for rubygems to make sense of the values in
> requirements because their entirely system dependent.
>
> In 2.0, gem metadata can be used to store these kinds of values for
> you to write a tool that will read them (which again will have to
> deal with the system dependent issues itself).
>

Does this mean we could have something like:

metadata["linux_requirements"] = ["libMagick.so >= 6.6.2"]

where can I find more information on the metadata?

thanks

jordi

[Evan Phoenix]

See below.

--
Evan Phoenix // ev...@phx.io

On Saturday, January 26, 2013 at 10:06 AM, Jordi Massaguer Pla wrote:

> Does this mean we could have something like:
>
> metadata["linux_requirements"] = ["libMagick.so >= 6.6.2"]

Yes, that's correct.

>
> where can I find more information on the metadata?

We haven't written many docs on it yet, but here is some: https://github.com/rubygems/rubygems/blob/master/lib/rubygems/specification.rb#L23-L35

[Erik Hollensbe]

On Jan 26, 2013, at 10:14 AM, Evan Phoenix <ev...@phx.io> wrote:

> See below.
>
> --
> Evan Phoenix // ev...@phx.io
>
>
> On Saturday, January 26, 2013 at 10:06 AM, Jordi Massaguer Pla wrote:
>
>> Does this mean we could have something like:
>>
>> metadata["linux_requirements"] = ["libMagick.so >= 6.6.2"]
> Yes, that's correct.
>>
>> where can I find more information on the metadata?
>
> We haven't written many docs on it yet, but here is some: https://github.com/rubygems/rubygems/blob/master/lib/rubygems/specification.rb#L23-L35

About two years ago Josiah Kiehl and I were working on a system that abused this metadata to provide a way for users to build/install their dependencies during "gem install". We didn't get that far code-wise (both of us moved cross-country shortly after that), but we did have a pretty good idea of how we wanted to do it. Happy to discuss it off-list if you're interested in what we came up with.

-Erik

[Jordi Massaguer Pla]

Quoting Evan Phoenix <ev...@phx.io>:

> See below.
>
> --
> Evan Phoenix // ev...@phx.io
>
>
> On Saturday, January 26, 2013 at 10:06 AM, Jordi Massaguer Pla wrote:
>
>> Does this mean we could have something like:
>>
>> metadata["linux_requirements"] = ["libMagick.so >= 6.6.2"]
> Yes, that's correct.
>>
>> where can I find more information on the metadata?
>
> We haven't written many docs on it yet, but here is some:
> https://github.com/rubygems/rubygems/blob/master/lib/rubygems/specification.rb#L23-L35

That looks very interesting. I was thinking thought that what would
make life easier is that everyone was using the same "key". Like
"linux_requirements" for example.

Do you think that there could be some recomendations on which key to
use for that purpose? I would not mind sending PR to every native gem
I use, but I do not know which key to use.

[Gary Weaver]

I think it would be better to stick with the current DSL looking
"add_*_dependency" type of thing and do a require at the top of the Gemfile
that would load that gem to extend Gem::Specification.

And since the name and version of the dependency could depend on platform
and tool used to list the loaded libraries, maybe the extending gem should
define command name specific methods, like for OS X that provides 'otool'
as a dynamic library lister:

spec.add_native_dependency 'otool', 'libSystem.B.dylib', '~> 159.1', '>=
159.1.0'

so that that gem would maybe do:
otool -L `which ruby`

and then parse that output to find the current version.

Then, for linux, that gem would use ldd and you'd need to specify:

spec.add_native_dependency 'ldd', 'libm.so.6', ['GLIBC_2.2.5'] # if array,
it is a list of valid versions (for versions that aren't x(.x)(.x))

Where your rubygems extending native library checking gem would do:
ldd -v `which ruby`

But, I don't think it is as clear with Windows. Some ways of checking DLLs
are discussed here:

http://stackoverflow.com/questions/602802/command-line-tool-to-dump-windows-dll-version
http://superuser.com/questions/381276/what-are-some-nice-command-line-ways-to-inspect-dll-exe-details

Nothing there that is built-in that I see- maybe you could bundle sigcheck
with the gem, though, if the license/owner allows that.

So, it wouldn't be terribly difficult to make it easy to use and visually
similar to the existing rubygems spec, but the native specific stuff is not
as straightforward, and ldd, etc. may potentially behave differently
depending on version, making that difficult. Wouldn't be trivial, overall,
to say the least, but sound like fun if you like long ongoing project
maintenance.

On Mon, Jan 28, 2013 at 6:22 AM, Jordi Massaguer Pla
<jmassa...@suse.de>wrote:

> Quoting Evan Phoenix <ev...@phx.io>:
>
> See below.
>>
>> --
>> Evan Phoenix // ev...@phx.io
>>
>>
>> On Saturday, January 26, 2013 at 10:06 AM, Jordi Massaguer Pla wrote:
>>
>> Does this mean we could have something like:
>>>
>>> metadata["linux_requirements"] = ["libMagick.so >= 6.6.2"]
>>>
>> Yes, that's correct.
>>
>>>
>>> where can I find more information on the metadata?
>>>
>>
>> We haven't written many docs on it yet, but here is some:

>> https://github.com/rubygems/**rubygems/blob/master/lib/**
>> rubygems/specification.rb#L23-**L35<https://github.com/rubygems/rubygems/blob/master/lib/rubygems/specification.rb#L23-L35>

>>
>
>
> That looks very interesting. I was thinking thought that what would make
> life easier is that everyone was using the same "key". Like
> "linux_requirements" for example.
>
> Do you think that there could be some recomendations on which key to use
> for that purpose? I would not mind sending PR to every native gem I use,
> but I do not know which key to use.
>
>
>

>> ______________________________**_________________
>> RubyGems-Developers mailing list
>> http://rubyforge.org/projects/**rubygems<http://rubyforge.org/projects/rubygems>
>> RubyGems-Developers@rubyforge.**org <RubyGems-...@rubyforge.org>
>> http://rubyforge.org/mailman/**listinfo/rubygems-developers<http://rubyforge.org/mailman/listinfo/rubygems-developers>
>>
>>
>
> ______________________________**_________________
> RubyGems-Developers mailing list
> http://rubyforge.org/projects/**rubygems<http://rubyforge.org/projects/rubygems>
> RubyGems-Developers@rubyforge.**org <RubyGems-...@rubyforge.org>
> http://rubyforge.org/mailman/**listinfo/rubygems-developers<http://rubyforge.org/mailman/listinfo/rubygems-developers>

[Erik Hollensbe]

On Jan 29, 2013, at 3:28 PM, Gary Weaver <garys...@gmail.com> wrote:

> I think it would be better to stick with the current DSL looking
> "add_*_dependency" type of thing and do a require at the top of the Gemfile
> that would load that gem to extend Gem::Specification.
>
> And since the name and version of the dependency could depend on platform
> and tool used to list the loaded libraries, maybe the extending gem should
> define command name specific methods, like for OS X that provides 'otool'
> as a dynamic library lister:
>
> spec.add_native_dependency 'otool', 'libSystem.B.dylib', '~> 159.1', '>=
> 159.1.0'
>
> so that that gem would maybe do:
> otool -L `which ruby`
>
> and then parse that output to find the current version.
>
> Then, for linux, that gem would use ldd and you'd need to specify:
>
> spec.add_native_dependency 'ldd', 'libm.so.6', ['GLIBC_2.2.5'] # if array,
> it is a list of valid versions (for versions that aren't x(.x)(.x))

As callous as this sounds, this actually doesn't solve anything. The proof is in your examples -- they're a part of the standard library for the respective platforms.

As soon as you need something like 'libferrous' of a specific version, you're boned. Also ldd/otool will never output the results of a gem's native dependencies, because ruby is never linked against them until the gem is required, and only indirectly. Ruby loads the gem's native object which is linked against the library that would be in the gemspec.

And this is all before we start talking about how to turn 'libferrous' into a set of packages or source to install that would allow you to compile the gem. That's the miasma.

-Erik

[James Tucker]

On Jan 29, 2013, at 3:45 PM, Erik Hollensbe <er...@hollensbe.org> wrote:

>
> On Jan 29, 2013, at 3:28 PM, Gary Weaver <garys...@gmail.com> wrote:
>
>> I think it would be better to stick with the current DSL looking
>> "add_*_dependency" type of thing and do a require at the top of the Gemfile
>> that would load that gem to extend Gem::Specification.
>>
>> And since the name and version of the dependency could depend on platform
>> and tool used to list the loaded libraries, maybe the extending gem should
>> define command name specific methods, like for OS X that provides 'otool'
>> as a dynamic library lister:
>>
>> spec.add_native_dependency 'otool', 'libSystem.B.dylib', '~> 159.1', '>=
>> 159.1.0'

Certainly we don't want to bind to specific tools, nor to particular file names. Binding to shared library names (linker names) and versions might be /slightly/ more protable, but it's all fraught with portability issues.

Either way, we should be using native linker libraries directly, not command line wrappers, to do support discovery.

>> so that that gem would maybe do:
>> otool -L `which ruby`
>>
>> and then parse that output to find the current version.
>>
>> Then, for linux, that gem would use ldd and you'd need to specify:
>>
>> spec.add_native_dependency 'ldd', 'libm.so.6', ['GLIBC_2.2.5'] # if array,
>> it is a list of valid versions (for versions that aren't x(.x)(.x))

Right now, this can all be done, and is done, in extconf. It's more portable than writing specific native code for each linker and loader, as it just uses the platform build tools to perform assertions. Problematic and inefficient as they may be, autotools work this way for this same reason. Maybe today we have few enough supported platforms that it's viable to write code that links the linkers, without a totally horrific combinatorial explosion of native code, but later, not so much.

In order to write the native code under discussion here, would require rubygems to have C code, which is against the current approach. If we could have native code, there are plenty of inefficiencies and other problems we could probably solve for many users. It's additionally worth noting that none of this discussion has yet considered the JVM, which further has potentially a multi-platform implication, if you're using a combination of native libraries and JNI. At this point you may find yourself wanting to assert the JVM like a platform, and the native platform itself. We already see issues in this area around RUBY_PLATFORM = "java", where "platform" is insufficiently defined for people.

> As callous as this sounds, this actually doesn't solve anything. The proof is in your examples -- they're a part of the standard library for the respective platforms.
>
> As soon as you need something like 'libferrous' of a specific version, you're boned. Also ldd/otool will never output the results of a gem's native dependencies, because ruby is never linked against them until the gem is required, and only indirectly. Ruby loads the gem's native object which is linked against the library that would be in the gemspec.

% otool -L nokogiri.bundle
nokogiri.bundle:
/usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.15.0)
/usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

> And this is all before we start talking about how to turn 'libferrous' into a set of packages or source to install that would allow you to compile the gem. That's the miasma.

This.

[Erik Hollensbe]

On Jan 29, 2013, at 7:12 PM, James Tucker <jftu...@gmail.com> wrote:
>> As callous as this sounds, this actually doesn't solve anything. The proof is in your examples -- they're a part of the standard library for the respective platforms.
>>
>> As soon as you need something like 'libferrous' of a specific version, you're boned. Also ldd/otool will never output the results of a gem's native dependencies, because ruby is never linked against them until the gem is required, and only indirectly. Ruby loads the gem's native object which is linked against the library that would be in the gemspec.
>
> % otool -L nokogiri.bundle
> nokogiri.bundle:
> /usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.15.0)
> /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0)
> /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
>

That object wouldn't exist if the dependencies weren't satisfied beforehand, as it wouldn't be able to be compiled. You'll note the original email talks about running against ruby, not a specific shared object. Binary gems could work with this, but with all respect let me know when that's a plausible reality for anyone not on windows.

Josiah and I had a system which was a small service and gem plugin that mapped dependency+version (provided via the metadata facility) to a platform-specific set of packages. Then based on the user-selected or detected platform it would install those packages, elevating privileges if necessary. It would then finish the gem installation which at that point should work no differently than it does now.

Hooks have been in rubygems that can make this work since 1.6 or so (and I believe this was around the time we came up with this idea). Someone just has to write it. That someone will likely not be Josiah or myself, but I'll be happy to detail this for anyone that's interested in building such a thing. It's not very complicated and there's a little code out there, but not much; I think it was written at the last philly.rb we both attended which was around 2 years ago, but it's a simple enough idea to get your head around regardless.

Metadata is arguably the perfect place for this for the reasoning I try to provide above. Third party tools can support it, devs can use those third party tools, and production systems don't have to if they don't want to. If you want a fancy DSL, I don't think anything keeps you from subclassing Gem::Specification.

It was geared towards developers. Making rubygems or mkmf satisfy system dependencies as a first class feature would make writing replacements for both a very appealing topic for sysadmins that have to support ruby stacks and don't work around both already.

[Jordi Massaguer Pla]

I was just thinking on something very simple. By adding metadata that
contains the name of the libraries required, this metadata can be
retrievend and, in most linux platforms, you can use rpm or dpkg to
know if that it is installed. But using rpm or dpkg would be something
run by the user, rubygems should only provide the name of the library,
that I believe should be the same for most linux platforms.

Does it has sense?

[Jordi Massaguer Pla]

>
> Josiah and I had a system which was a small service and gem plugin
> that mapped dependency+version (provided via the metadata facility)
> to a platform-specific set of packages. Then based on the
> user-selected or detected platform it would install those packages,
> elevating privileges if necessary. It would then finish the gem
> installation which at that point should work no differently than it
> does now.
>
> Hooks have been in rubygems that can make this work since 1.6 or so
> (and I believe this was around the time we came up with this idea).
> Someone just has to write it. That someone will likely not be Josiah
> or myself, but I'll be happy to detail this for anyone that's
> interested in building such a thing. It's not very complicated and
> there's a little code out there, but not much; I think it was
> written at the last philly.rb we both attended which was around 2
> years ago, but it's a simple enough idea to get your head around
> regardless.
>
> Metadata is arguably the perfect place for this for the reasoning I
> try to provide above. Third party tools can support it, devs can use
> those third party tools, and production systems don't have to if
> they don't want to. If you want a fancy DSL, I don't think anything
> keeps you from subclassing Gem::Specification.

I agree. The missing piece is some kind of convention or
recommendation on the metadata, so that I do not have to fork every
native gem I plan to use and maintain them on my own but I can send a
Pull Request instead and have some possibilities that the owner
accepts that.

Which metadata key and values were you using or would you suggest?

[Gary Weaver]

On Tue, Jan 29, 2013 at 6:45 PM, Erik Hollensbe <er...@hollensbe.org> wrote:

> As callous as this sounds, this actually doesn't solve anything. The proof
> is in your examples -- they're a part of the standard library for the
> respective platforms.
>

Yep, you're right. Was grasping for tools at the end of the day to solve it
quickly, could tell that it wasn't listing all loaded libraries, and
shouldn't have hit send on that. Understand that otool and ldd are not
looking at libraries loaded dynamically in rubygems, etc., so sorry about
that.

The intention in the beginning was to try to discourage just using metadata
because that looks nasty. If a gem can extend Gem::Specification to add
additional methods like add_native_runtime_dependency, etc. then problems
with missing dependencies can be caught at the same time as the rest rather
than having to use something else later that looks at
Gem::Specification.metadata.

Maybe that isn't a good idea, though.

[Gary Weaver]

On Tue, Jan 29, 2013 at 10:12 PM, James Tucker <jftu...@gmail.com> wrote:

>
> Right now, this can all be done, and is done, in extconf. It's more
> portable than writing specific native code for each linker and loader, as
> it just uses the platform build tools to perform assertions. Problematic
> and inefficient as they may be, autotools work this way for this same
> reason. Maybe today we have few enough supported platforms that it's viable
> to write code that links the linkers, without a totally horrific
> combinatorial explosion of native code, but later, not so much.
>

But extconf.rb/mkmf is meant for C-extension building isn't it? I got the
impression that the requirement was that they just wanted to see what
version of a library was loaded.

>
> In order to write the native code under discussion here, would require
> rubygems to have C code, which is against the current approach.

I was just suggesting extending the Gem::Specification DSL in another gem
because I didn't like metadata being used for something like this because
it is clunky-looking.

> If we could have native code, there are plenty of inefficiencies and other
> problems we could probably solve for many users. It's additionally worth
> noting that none of this discussion has yet considered the JVM, which
> further has potentially a multi-platform implication, if you're using a
> combination of native libraries and JNI. At this point you may find
> yourself wanting to assert the JVM like a platform, and the native platform
> itself. We already see issues in this area around RUBY_PLATFORM = "java",
> where "platform" is insufficiently defined for people.
>

http://stackoverflow.com/questions/1007861/how-do-i-get-a-list-of-jni-libraries-which-are-loaded/14608470#14608470

In JRuby:

require 'java'
import 'java.lang.ClassLoader'
f = ClassLoader.java_class.declared_field('loadedLibraryNames')
f.accessible = true
f.value(ClassLoader.system_class_loader).to_array.to_a

If using Java with a different Ruby interpreter, use something similar. If
is so file then could get version from name, but with dylib, the only way I
know is to shell out, e.g. in OS X:

`otool -L
"/Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk/Contents/Home/jre/lib/libzip.dylib"`

If there is another way to get version that doesn't require shelling out,
that would be cool to know.

>
> > As callous as this sounds, this actually doesn't solve anything. The
> proof is in your examples -- they're a part of the standard library for the
> respective platforms.
> >
> > As soon as you need something like 'libferrous' of a specific version,
> you're boned. Also ldd/otool will never output the results of a gem's
> native dependencies, because ruby is never linked against them until the
> gem is required, and only indirectly. Ruby loads the gem's native object
> which is linked against the library that would be in the gemspec.
>
> % otool -L nokogiri.bundle
> nokogiri.bundle:
> /usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current
> version 9.15.0)
> /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current
> version 3.26.0)
> /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current
> version 10.8.0)
> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current
> version 7.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 169.3.0)
> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
> version 228.0.0)
>

Yeah, so that list doesn't help. Have to call it against the dylib itself
that is loaded, but I'm not sure how to get a list of those at runtime
(other than the method that can be used in JRuby above). Do you know (so-
not for c compilation/not in extconf.rb, but just something you could call
to get a list of loaded libraries).

>
> > And this is all before we start talking about how to turn 'libferrous'
> into a set of packages or source to install that would allow you to compile
> the gem. That's the miasma.
>
> This.
>

Ok, my understanding was that the C extension may have been compiled when
the library was available, but the question is about whether the library is
actually loaded on gem load- this could be long after the gem's c
extensions were compiled and maybe everything is not available that was, or
maybe some library has been updated that won't work with the compiled c
extension.

Thanks!

[Jordi Massaguer Pla]

Quoting Gary Weaver <garys...@gmail.com>:

> On Tue, Jan 29, 2013 at 10:12 PM, James Tucker <jftu...@gmail.com> wrote:
>
>>
>> Right now, this can all be done, and is done, in extconf. It's more
>> portable than writing specific native code for each linker and loader, as
>> it just uses the platform build tools to perform assertions. Problematic
>> and inefficient as they may be, autotools work this way for this same
>> reason. Maybe today we have few enough supported platforms that it's viable
>> to write code that links the linkers, without a totally horrific
>> combinatorial explosion of native code, but later, not so much.
>>
>
> But extconf.rb/mkmf is meant for C-extension building isn't it? I got the
> impression that the requirement was that they just wanted to see what
> version of a library was loaded.
>
>

The requirement was to know about library dependencies before building
the native extension. Thus, you can not use tools like ldd because the
native library has not yet been compiled...

[Gary Weaver]

On Wed, Jan 30, 2013 at 12:00 PM, Gary Weaver <garys...@gmail.com> wrote:

>
> Do you know (so- not for c compilation/not in extconf.rb, but just
> something you could call to get a list of loaded libraries).
>

(note: otool mentioned before is specific to xcode/xcode cmd line utils.)

Answering my own question- requires shelling out, but for OS X:

`vmmap
#{Process.pid}`.scan(/"([^"]+)"|(\S+)/).flatten.compact.delete_if{|s|
s.length > 0 && s[0] != '/'}

lists all the dylibs, bundles, ruby's exe.

And in linux:

`pmap #{Process.pid}`.scan(/"([^"]+)"|(\S+)/).flatten.compact.delete_if{|s|
s.length > 0 && s[0] != '/'}

In Windows I think need to use listdlls available at:
http://technet.microsoft.com/en-us/sysinternals/bb896656.aspx
which maybe could be packaged in the gem. Have not tried it, but I think it
lists for the current process, so could list for ruby?

Anyway, I'll shut up now.

[Hugh Sasse]

On Wed, 30 Jan 2013, Jordi Massaguer Pla wrote:

> Quoting Gary Weaver <garys...@gmail.com>:
>
> > On Tue, Jan 29, 2013 at 10:12 PM, James Tucker <jftu...@gmail.com> wrote:
> >
> > >
> > > Right now, this can all be done, and is done, in extconf. It's more
> > > portable than writing specific native code for each linker and loader, as
> > > it just uses the platform build tools to perform assertions. Problematic
> > > and inefficient as they may be, autotools work this way for this same
> > > reason. Maybe today we have few enough supported platforms that it's
> > > viable
> > > to write code that links the linkers, without a totally horrific
> > > combinatorial explosion of native code, but later, not so much.
> > >
> >
> > But extconf.rb/mkmf is meant for C-extension building isn't it? I got the
> > impression that the requirement was that they just wanted to see what
> > version of a library was loaded.
> >
> >
>
> The requirement was to know about library dependencies before building the
> native extension. Thus, you can not use tools like ldd because the native
> library has not yet been compiled...

Claiming almost no expertise here (I've used it once):
pkg-config is supposed to solve this, I think, and seems to be
cross-platform.

https://en.wikipedia.org/wiki/Pkg-config

http://www.freedesktop.org/wiki/Software/pkg-config

It is used by autotools.
http://www.flameeyes.eu/autotools-mythbuster/pkgconfig/index.html

It is GPL. Licensing debates may ensue...

HTH
Hugh