On Mon, 2005-06-13 at 19:34 +0200, Geert Hendrickx wrote:
> On Mon, Jun 13, 2005 at 07:02:48PM +0200, Julio M. Merino Vidal wrote:

> > You'd set FILESDIR to point to distcc/files.  But wait...
> 
> Nice, thanks!  And for patches?  PATCHESDIR?  

PATCHDIR or PATCHESDIR; I never remember which one is it and have to
look at other packages.  (Also look at DISTINFOFILE.)

> > You'd probably do this in a slightly different manner.  Instead of
> > making distcc-gtk include _everything_ that is already in distcc, change
> > it to provide the new frontend plus the icon plus the desktop file only.
> > Then, add a dependency on distcc.  This way the two packages will not
> > conflict (and will hopefully be easier to manage).
> 
> I've been thinking about this, too.  But I opted for the conflicting
> packages because they both compile from the same source tarball, just
> with different ./configure options.  Much like mozilla vs mozilla-gtk2.  
> Distilling the gtk frontend would probably require more work.  

mozilla is not the same case as this one.  In mozilla, giving a
different build flag results in a different program which cannot be
installed alongside the other one (in theory; our packages allow it by
renaming stuff).  This example is not very appropriate; a clearer one
may be wm/icewm{,-gnome,-imlib}.

In the distcc scenario, giving the --enable-gtk flag does not change the
way the common programs are built by default; it only adds new stuff to
the build (i.e., the gtk frontend).  Similar examples include
GConf2/GConf2-ui, gnome-vfs2-*, libao-*, gst-plugins-*,
swfdec/swfdec-gtk2 and several more.

It may be a bit more work, but it's definitely worth it from the binary
packages' point of view.  And, if the gtk frontend is provided in an
independent subdirectory within the source package, things will be very
easy by using BUILD_DIRS/INSTALL_DIRS.

Cheers,

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/