Re: packaging libAfterBase and libAfterImage

Graydon (
Wed, 21 May 2003 19:22:36 -0400

On Wed, May 21, 2003 at 06:03:01PM -0400, Sasha Vasko
<> scripsit:
> Graydon wrote:
> > The makefiles for libAfterBase and libAfterImage don't support
> > DESTDIR (as in, make $DESTDIR install ) so they more or less can't
> > be packaged, there being no way to redirect the install off into an
> > empty directory.
> > 
> > Is there a known workaround for this?
> Currently you can specify what directory to install to , by using
> switches to ./configure.  I'm not really aware of how packaging is
> done nowdays, being preocupied with writing the code in the first
> place, but I'm open to suggestions, and even more open to patches.

That's not the problem; I'm using 

configure --enable-sharedlibs \
          --prefix=/usr \
          --mandir=/usr/share \
          --libdir=/usr/lib \

And that works fine; everything goes the places that are standard on a
Red Hat system.

The problem is that the 'install' step in RPM doesn't want to put things
there; it wants to put things in the build root, and *then* where
they're going to go, so you get:


as the install path and the package system can do checks for what you
built but didn't package and other such things; older versions of RPM
would let you pull stuff from the main file system, and I'm sure there's
a way to club it into doing that still, but enough people inadvertently
packaged all of /usr/bin that it's not straightforward to turn off the

The usual way to handle the install step is

%install	#RPM installation macro, does stuff for you

where $DESTDIR gets prepended to all the path names for the install.

This needs makefiles (like the GNU standard automake ones) that support
DESTDIR, or some other way to prepend a 'package root' directory that
will be respected by all the makefiles invoked by 'make install'.

> > Anything that won't go into an RPM these days is more or less
> > useless for getting new users and interest in the project and all
> > that good stuff, so I think this is a serious problem.
> > 
> > The obvious solution is conversion to automake, which I'm reluctant
> > to
> I don't think that any kind of conversion is needed. I could imagine
> that rather minor changes will be required to accomplish what you
> want.  afaik, all automake does is that it generates s for
> you instead of you doing that manually.

It also adds a wodge of GNU standard stuff, the DESTDIR piece of which I
was after.

> But since those were created already and include somewhat custom code,
> I do not really want to trash them altogether, and rather fix them.

Fair enough; that's why I asked.

> > undertake (since I don't know automake at all) and which I'm
> > reluctant to consider trying anyway without asking people if there's
> > a reason not to do so.
> Actually I have a question here. What is your interest? Are you
> looking into creating some packages? or just wandering ?

I have been trying to create some packages, and have reluctantly
concluded that there isn't currently any way to do it without hacking
the makefile.

Unfortunately, I don't know make at all and I don't understand those
make files, so my 'I wonder if this is easy' take on sticking DESTDIR in
there was not a success. :)

RPMs are easy, though, and libAfter isn't itself complicated to package.

I'm using RH 9; the included spec file for 1.99 builds fine without the
RH mods to the menus, which are (I think) obsolete anyway, but of course
I need the libAfter stuff, too, and while it builds fine I'm determined
to package it properly in the interests of my long term sanity.

-- | Uton we hycgan    hwaer we ham agen,
                 | ond thonne gedhencan    he we thider cumen.
                 |   -- The Seafarer, ll. 117-118.
The AfterStep Window Manager for X User's Mailing List