[projectM-devel] [archive] destdir

[Hai Z. <ha...@gm...>]

For sake of history...

---------- Forwarded message ----------
From: Hai Zaar <ha...@gm...>
Date: Feb 21, 2006 3:18 PM
Subject: Re: destdir
To: Peter Sperl <ps...@us...>


Hi!

>      Thanks a lot for you comments about DESTDIT and
> projectM 0.97.  The thing is that 0.97 is now old news, and
> I'm working on releasing 0.98 in a few days (the 24th).  So,
> with the new version, I know you can use prefix=3D/whatever to
> install the library wherever you want, but I don't know if
> this is the functionality you need. Anyway, I suck at
> autotools and all things realted to it.  If you could look
> at the packages in CVS, in order to have them install
> properly, I would be very appreciative.
I'll be glad to send you patches against CVS version, but for some
reason I can not checkout it:
   cvs -d:pserver:ano...@cv...:/cvsroot/xmms-projectm logi=
n
   Logging in to
:pserver:ano...@cv...:2401/cvsroot/xmms-projectm
   CVS password:
   cvs [login aborted]: end of file from server (consult above messages if =
any)
Have you saw similar problems before? May be you just send me current
CVS snapshot tarball?

>The problem I have
> right now is how to have the executable know where he's been
> installed. (if you choose /home/you/prjm, then how does
> libprojectM.so know to look in /home/you/prjm/share for his
> resources?).  Thanks, let me know.
Well, I can think of two ways:
1. Use configuration file. Configuration file can be automatically
created during configure/make/make install stages to match prefix
specified to configure. It can be done straight-forward with
autoconf/make (I can do it). The next part is to update your sources
to read that config file.
If user moves files around, it will have to update that configuration
file. This may be both good and bad thing - its gives you power, but
possibly requires more work when you move things around.

2. Second option is to read /proc/self/maps file and search its
contents for your library name - then you'll see the full path to you
library. This sounds more 'cool', but it has its contras as well. I'll
try to explain:
Software install principles have two notions(variables) among the
other things: 'prefix' and 'DESTDIR'.
prefix - defines where are 'bin', 'lib', 'include', 'share' dirs
_realative_ to the root ('/').
DESTDIR - defines where is the root ('/').

prefix is usally something like /usr, /usr/local or /opt. and then
package should look for its, say, configuration files in $prefix/etc.

By default DESTDIR is blank and actually defines what to prepend to
'prefix' when you _install_ files. I.e. running ./configure
--prefix=3D/usr and  make DESTIDR=3D/myprogs/projectM install will create
/myprogs/projectM/{bin,lib,include,...}, and if the project treats
'prefix' in the right way, it will look for its, say, shared data in
/usr/share and _not_ in /myprogs/projectM.
Why is it good? - you can just link /myprogs/projectM/bin/* to
/usr/bin/, /myprogs/projectM/lib/* to /usr/lib/, etc. and then you not
need to chage your "PATH", LD_LIBRARY_PATH, and any other system wide
configuration - the package assumes it sits under /, while actually it
sits under /myprogs/projectM.
Now the catch with the second method of finding where my libraries
are: if /usr/lib/libprojectM.so is linked to
/myprogs/projectM/lib/libprojectM.so, then /proc/self/maps will have
/myprogs/projectM/lib/libprojectM.so in it (and not
/usr/lib/libprojectM.so you'd like it to), and that may break things
(I can provide examples if you want).

I hope I've explained myself right.

P.S. Do you have any mailing list for projectM?

--
Zaar


--
Zaar