[Cairo] Making it easier to build Cairo from CVS.

[James Henstridge]

On 6/11/2003 1:44 AM, Carl Worth wrote:

>On Nov 5, James Henstridge wrote:
> > For those interested in an easier way to build cairo from CVS, you might 
> > want to try out jhbuild.
>
>Thanks James. This should help ease what has historically been a
>rather painful process with cairo. I just ran through the
>instructions, and after working through a couple snags during jhbuild
>installation (noted below), I was able to download and build all cairo
>modules with a single "jhbuild build cairo".
>
>Well done!
>
> > Comments on jhbuild and the setup instructions are welcome.
>
>Here are some of my comments after a very brief look at
>jhbuild. Please let me know if there's some jhbuild-specific list
>that would be more appropriate for all of this.
>
>1) Is there a good reason to install in $(HOME)/bin by default instead
>   of say, /usr/local/bin?
>  
>
One of the aims was to allow building everything without needing root 
access.  Hence it defaults to ~/bin.  You will also notice that the 
jhbuild shell script installed there actually runs the Python files in 
the checkout directory.

>2) Is install-check a generic program? Or should it get a name like
>   jhbuild-install?
>  
>
It is a generic program.  It checks to see if the arguments follow a 
certain form, and if the file being copied is a .h file.  If so, then 
the contents of the new and currently installed version are compared.  
If they are the same, then install-check does nothing.  If they differ, 
then install-check execs the normal install program.  If the arguments 
to install-check aren't recognised, the normal install program is exec'd.

>3) The "make install" step says "Don't forget to create ~/.jhbuildrc"
>   but doesn't provide any indication where I might find a sample file
>   or instructions on how to roll my own.
>
>4) I usually build things as a normal user, and then make install to
>   /usr/local as root. Could jhbuild be made to operate in a two-user
>   mode like this somehow? Maybe by cooperating with sudo or
>   something?
>  
>
It would probably be pretty easy to modify jhbuild to call "sudo make 
install" instead of "make install".  I never really paid much attention 
to this sort of setup, since I install to a prefix owned by my user account.

>5) I notice that the modulesets have hand-coded dependencies in
>   them. Is there a way this information could be automatically lifted
>   from the several *.pc files from the packages themselves?
>
>   Maybe this information could be in a file on the CVS server
>   containing the sources? And then perhaps that file could be
>   automatically updated when new *.pc.in files were committed or
>   something like that? I don't know.
>  
>
The dependency information needs to be separate from the modules 
themselves (you need to know what to check out from CVS before you can 
check it out).  So far I have settled for maintaining the dependency 
information with jhbuild because it seemed easiest to maintain.  It also 
made it quite easy for other Gnome hackers to commit fixes to the 
.modules files when things changed.

I don't know if parsing .pc.in files is going to work very well.  There 
are a number of reasons:

   1. some of the stuff substituted in by the configure script may be
      important.  Looking at the final .pc file is also difficult, since
      it is only available once the package has successfully been built ...
   2. a pkg-config file gives information about what dependencies are
      needed for other packages to use the library.  This is quite often
      different to what is needed at build time (eg. some package might
      require intltool or gtk-doc to build, but applications using the
      library don't need them).
   3. Most applications don't have .pc files since they aren't libraries.

Adding support for giving a full URI for a .modules file might work okay 
though (set it up to cache the file and update it at regular intervals).

>6) It seems there should be a separation of jhbuild the tool, and the
>   configuration data, (modulesets and dependencies) that it acts
>   upon. That would make it easier to use jhbuild more generally with
>   other repositories of code.
>  
>
Yep.  This is one area where jhbuild could use some modifications to 
scale up.

>7) Does jhbuild have anyway to deal with changes in dependencies? For
>   example cairo->xft should now be cairo->fontconfig,freetype. It
>   seems it would be nice to have some sort of "jhbuild update" that
>   refreshes its database of dependencies. Otherwise, I'll have to go
>   manually cvs update/build/install jhbuild itself --- and that's the
>   kind of thing I'm trying to get rid of by using jhbuild.
>
>   Actually, "jhbuild update" needn't be a separate command. Since
>   jhbuild already depends on a network connection, I don't see why it
>   shouldn't always try to refresh its dependency database.
>  
>
Auto-updating is a feature I have been meaning to implement, but haven't 
got round to yet.  The original plan was to get jhbuild to do a "cvs 
update" on its checkout then exec() itself.  It might need to be a bit 
different if the module info is separated.

For now, the answer is to get the .modules file updated in Gnome CVS, 
then run "cvs update".

[I'll look at updating the cairo dependencies later on today though]

>8) I ran "jhbuild build cairo" twice in a row. The second time it
>   seemed to be doing lots of unnecessary steps, (looked like "make
>   install" all over the place). This was only really a problem with
>   fontconfig which has a very slow "make install" step. It would be
>   nice to eliminate all that.
>  
>
"jhbuild build" will run through the entire module list.  It doesn't 
actually check to see if anything has changed in the module, instead 
relying on make to not rebuild things unnecessarily, and the 
install-check script to prevent rebuilds due to mtime changes on 
installed headers.  It isn't perfect, but works pretty well.  Is some 
part of fontconfig always getting rebuilt on "make install"?

James.

-- 
Email: james at daa.com.au
WWW:   http://www.daa.com.au/~james/