Consider ppp, as ppp was cherry-picked by Federico [1]. It has been established
we can't check the package name, as every distro has different names, and we're
not maintaining a list for every distro.

When NetworkManager checks for ppp, it does via configure.ac:
  AC_CHECK_HEADERS(pppd/pppd.h
Which compiles a C program with the following:
  #include <pppd/pppd.h>
ppp has the following file [2]:
  /usr/include/pppd/pppd.h

How about this design?
1. a new JHBuild config variable 'system_prefix' that defaults to '/usr'.
2. A new tag <systemfile>

  <systemmodule id="ppp" >
     <systemfile>include/pppd/pppd.h</systemfile>
     <branch repo="system" version="2.4"/>
  </systemmodule>

If the user has software in different prefix, that can be set via
system_prefix. E.g.:
system_prefix = ['/usr', '/usr/local']

In this first design, only 1 <systemfile> can be specified.

However, this design falls down for Foresight linux (due to Conary package
management system), Sourcemage linux, and other rpath/chroot package management
systems.

[1] http://mail.gnome.org/archives/desktop-devel-list/2012-April/msg00040.html
[2] https://admin.fedoraproject.org/pkgdb/builds/show/F-16-x86_64/ppp-devel/0/2.4.5/18.fc16/i686?_csrf_token=80d26c4545932a4aba52edde124374c1af1b08b0

With the current ecosystem of distributions I believe the only way is indeed to start maintaining mappings of package names in jhbuild, but I am not sure about the way to declare this.

Something like:

<systemmodule id="ppp">
  <package distro="debian">ppp-dev</package>
  <package distro="fedora">ppp-devel</package>
</systemmodule>

sounds like too much work, one line per distro while most of them will share the same package names; therefore, perhaps something like:

<systemmodule id="ppp">
  <package>ppp-dev,ppp-devel</package>
</systemmodule>

And jhbuild would check for the presence of one of the packages? An alternative would simply be to
skip the distro attribute off the first proposal:

<systemmodule id="ppp">
  <package>ppp-dev</package>
  <package>ppp-devel</package>
</systemmodule>

But this will fail for more complex cases, like libxslt, which is a dependency of modules needing to build agaisnt libxslt, but also of modules that use xsltproc. In that case, the second proposal could be enhanced as is:

<systemmodule id="ppp">
  <package>libxslt-dev,libxslt-devel</package>
  <package>xsltproc,libxslt-utils</package>
</systemmodule>

But it will fail if all distributions do not split packages in the same way :/ Therefore we could define couples (or triples, tuples generally) :

<package>
  <packages>libxslt-dev,xsltproc</packages> <!-- on debian -->
  <packages>libxslt-devel,xsltproc</packages> <!-- on fedora -->
</package>

I'd like to try as hard as possible to avoid package names.  How about instead:

This component requires "xsltproc" in $PATH:

<dep type="path" name="xsltproc"/> 

This component requires gio-2.0.pc:

<dep type="pkgconfig" name="gio-2.0.pc"/>

This component requires a particular header:

<dep type="c_include" name="pppd.h"/>

Imagine a future where one can query a module for its dependencies by running ./configure like:

./configure --enable-selinux --disable-foobar --print-dependencies

Which would then output:
path(xsltproc)
pkgconfig(gio-2.0.pc)
c_include(pppd.h)

to stdout.

Okay, but honestly filenames are really impractical on debian based systems, as such a system requires to have the non-standard apt-file package installed and updated.

(In reply to comment #4)
> Okay, but honestly filenames are really impractical on debian based systems, as
> such a system requires to have the non-standard apt-file package installed and
> updated.

Yeah...but the package name thing is a long term hell =/  Apt file should be fixable right?  It's not really great on Fedora at least either, since the lookaside filelists.xml is large and...well, it's XML.

But if we were going to go down the package name road, it seems like we could at least have some distribution-detection thing that's at least intelligent enough to say "fedora => -devel, debian -> -dev, gentoo -> nothing".  So the dep could be like:

<systemmodule package-prefix="ppp"/> or something, then we know if debian, suffix with "-dev" etc.

I agree with Colin. It seems much better to use whatever filename -> package mapping mechanism the distribution already has (yum, apt-file, ...) instead of starting to maintain our own mapping.

filename -> package mapping would need to happen at start of every 'jhbuild build' and performed for every <systemmodule>. This could be slow. Yes, some caching could be peformed - if distro's provide a way to check if the package database has been updated.

It seems the consensus we need to check the package database for pppd.h. But I don't see why?

> It seems the consensus we need to check the package database for pppd.h. But I
> don't see why?

We need to check the filesystem for /usr/include/pppd/pppd.h.

If it is not present, we tell the packaging system: 'Make /usr/include/pppd/pppd.h appear'.

So the filename -> package mapping will only be consulted if the file is not present.

(In reply to comment #8)
> So the filename -> package mapping will only be consulted if the file is not
> present.

Thank you for clearing it up for me.

JHBuild already does the mapping for <pkg-config>, let's continue in the same fashion beyond <pkg-config> for pppd.h.

If we are proposing enhancements/changing this mapping, that's a topic for a different bug.

I agree with Colin in comment 3. I want to avoid package names.

I do like Colin's XML from comment 3. I do have some questions.
1. Would we keep <pkg-config> within <autotools> or would it change to <dep type="pkgconfig" name="blah"/> format?
2. I'm concerned about using <dep> for 2 purposes. The following examples are valid XML but don't make sense. If we used different tag names, the xml parser would correctly raise an error.

  <systemmodule id="ppp" >
    <dep package="glib"/> <!-- package= makes no sense for systemmodule -->
    <branch repo="system" version="2.4"/>
  </systemmodule>

  <autotools id="cogl">
    <dependencies>
      <dep package="glib"/>
      <dep type="c_include" name="pppd/pppd.h"/> <!-- makes no sense -->
    </dependencies>
  </autotools>

Scrap my 'system_prefix' idea from comment 1. JHBuild should work like autoconf's AC_CHECK_HEADERS. Given the following:

  <dep type="c_include" name="pppd/pppd.h"/>

JHBuild will build a 'include path list' by checking:
1. module_autogenargs[module] for include path (-I) in CPPFLAGS.
2. module_autogenargs[module] for include path (-I) in CFLAGS (in case the user has incorrectly placed the include path in CFLAGS rather than the correct CPPFLAGS)
3. module_autogenargs[module] for include path (-I) in CXXFLAGS  (in case the user has incorrectly placed the include path in CXXFLAGS rather than the correct CPPFLAGS)
4. include path (-I) in JHBild config 'cflags'
5. include path (-I) in environment variable CPPFLAGS
6. include path (-I) in environment variable CFLAGS (if user misconfigured)
7. include path (-I) in environment variable CXXFLAGS (if user misconfigured)


Then JHBuild will check for pppd/pppd.h from the 'include path list'.

Created attachment 217754 [details] [review]
enhance <systemmodule> to support path dependencies

Can now add a program as a system dependency. For example, ruby:
<systemmodule id="ruby" >
  <branch repo="system" version="1.8"/>
  <systemdependencies>
    <dep type="path" name="ruby"/>
  </systemdependencies>
</systemmodule>

Version is not checked, but required as version is shown in the help
message.

Dep type="c_include" is not implemented yet.

Created attachment 218413 [details] [review]
enhance <systemmodule> to support path dependencies


Updated patch now supports c_include and path dependencies.

Can now add a program as a system dependency. For example, ruby:
  <systemmodule id="ruby" >
    <branch repo="system" version="1.8"/>
    <systemdependencies>
      <dep type="path" name="ruby"/>
    </systemdependencies>
  </systemmodule>

Can now add include files as a system dependency. For example, ppp:
  <systemmodule id="ppp" >
    <branch repo="system" version="2.4"/>
    <systemdependencies>
      <dep type="c_include" name="pppd/pppd.h"/>
    </systemdependencies>
  </systemmodule>

Version is not checked, but required as version is shown in the help
No 'jhbuild sysdeps --install' support. That can be the topic of another bug.

I'll commit the patch in a few weeks, if no objection.

Comment on attachment 218413 [details] [review]
enhance <systemmodule> to support path dependencies

Committed.
http://git.gnome.org/browse/jhbuild/commit/?id=03d8f544daf65c5196da88a6627f917371582f2c

And documentation:
http://git.gnome.org/browse/jhbuild/commit/?id=fd6e08aeb253a2c0eb3d4c9ac4e508dc29383339

Ok, but has anyone looked at using this for the 3.6 moduleset?  Like the WebKit depending on ruby?

(In reply to comment #15)
> Ok, but has anyone looked at using this for the 3.6 moduleset?  Like the WebKit
> depending on ruby?

I was planning on working on that next. I created a new bug - bug 681342.