There are at least two problems here that I've been thinking about for a long time, and they're largely related:

For a long time I've used my "three layers" system in dealing with jhbuild, giving me an environment that contains things such as this:

XDG_DATA_DIRS="/home/desrt/.cache/lcl/share:/home/desrt/.cache/jhbuild/install/share:/usr/local/share:/usr/share"

My three layers are:

 - the system (/usr and /usr/local)

 - jhbuild (~/.cache/jhbuild/install)

 - my "lcl" layer (~/.cache/lcl)

My system is just my distribution.  I only ever install stock packages in the jhbuild prefix, and I use my "lcl" layer for the stuff that I'm actually working on.

I also have three terminals for each of these layers: my normal terminal, one that runs "jhbuild shell" and one that runs a script that sets up my environment variables correctly for "lcl" (as above, but with about 10 variables).

Currently, I do this very manually -- I just have a script that sets up various environment variables (LD_LIBRARY_PATH, PKG_CONFIG_PATH, XDG_DATA_DIRS, etc).

What would be nice is if I had a way to get jhbuild to do its normal set of environment modifications on the paths that I specify, including the possibility of multiple paths, and including the possibility of ignoring jhbuildrc (although it would also be interesting to specify this in jhbuildrc).

We could add a --prefix switch to 'jhbuild run' and 'jhbuild shell' that cause it to ignore jhbuildrc and use the specified prefix.  By default it would use the one found in jhbuildrc.  Multiple prefixes could be supported, eg:

  jhbuild shell --prefix=~/.cache/lcl:~/.cache/jhbuild/install

This would let me get rid of my lcl environment setup script and replace it with a call to jhbuild.

So much for that problem.



The second, related problem: on BSD systems, we have the base system in /usr and 3rd party packages in /usr/local.  The dynamic linker knows about /usr/local/lib but the compiler and linker don't know about /usr/local/include and /usr/local/lib (respectively).

This means on FreeBSD, this is a mandatory part of your jhbuildrc:

  os.environ['C_INCLUDE_PATH'] = '/usr/local/include'
  os.environ['CPLUS_INCLUDE_PATH'] = '/usr/local/include'
  os.environ['LDFLAGS'] = '-Wl,-Y/usr/local/lib'

It is worth noting that jhbuild assigns values to all of these variables as part of its normal setup of the environment for its own prefix.  It would be nice if we could get jhbuild to have some "/usr/local mode" by which, in addition to its own prefix, it setup the environment for packages installed in /usr/local as well.  This could be a normal config variable like 'usr_local_mode = True', or it could be a more generic feature such as "additional_prefixes = ['/usr/local']", which seems a bit nicer.  In any case, we would want to enable it by default on BSD.


All of this stuff is handled in config.py in a function called 'setup_env()' which is a method on the Config class and currently very much tied to use of 'self.prefix' for determining the values of all of these variables.

This is a pretty typical example:

        includedir = os.path.join(self.prefix, 'include')
        addpath('C_INCLUDE_PATH', includedir)
        addpath('CPLUS_INCLUDE_PATH', includedir)

where 'addpath' is a function to add a path to the start of a ':'-separated variable.

Sometimes we take care to manage "default values":

        if not 'XDG_DATA_DIRS' in os.environ:
            os.environ['XDG_DATA_DIRS'] = '/usr/local/share:/usr/share'
        xdgdatadir = os.path.join(self.prefix, 'share')
        addpath('XDG_DATA_DIRS', xdgdatadir)

I think it would be nice if we could split out this functionality a bit and have it take an arbitrary prefix (or prefixes) to setup environment for.  We could then have the config code call out to it for the jhbuildrc prefix in the normal case, but we could also entertain more interesting cases as well.

Some less-invasive approaches are possible here.  We could handle the "/usr/local mode" more pragmatically by limiting its scope to the include paths and LDFLAGS (which seems to be all that is really needed).  There is some badness here, though with respect to some of the other variables (see bug 720118 for a previous mention of GI_TYPELIB_PATH being broken, for example).  I think adding more and more exceptions here is likely to slowly get us into a place where we wish we had handled in a less ad-hoc way.

We could also handle the 'jhbuild run --prefix=...' thing by whipping up a fake config.  I've already realised while writing this report that the best thing for me to do (without needing jhbuild changes) would be to create a jhbuildrc.lcl file (containing "prefix='~/.cache/lcl'") and use this line:

 jhbuild run jhbuild -f ~/.cache/lcl shell

in order to get the two layers of environment setup properly.


The combination of both of these circumstances together suggests that maybe we should be looking at making this code a bit more flexible, however...