projectm-devel

[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

[projectM-devel] [archive] destdir

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

For the sake of history...

---------- Forwarded message ----------
From: Hai Zaar <ha...@gm...>
Date: Mar 5, 2006 9:32 AM
Subject: Re: destdir
To: Peter Sperl <ps...@gm...>


On 3/5/06, Peter Sperl <ps...@gm...> wrote:
> Thanks!  This sounds perfect.
>
> I have some questions.
>
> Why is the default sysconfdir /usr/etc/projectM? Why not
> $prefix/share/projectM or just /etc/projectM?
Autoconf defaults sysconfdir to $prefix/etc. Since default prefix is /usr..=
...
But config files are installed in $sysconfdir/projectM. So if you run
configure with --prefix=3D/usr and --sysconfdir=3D/etc, then all config
files will be in /etc/projectM, as you'd expect.

>
> I don't understand the problem with the autogen.sh script. I wrote it so
> that right after I checked out of CVS, I could just run autogen.sh instea=
d
> of typing in aclocal/autoreconf/automake/libtool/etc. I
> mean, it just calls all the autotools so that I don't have to do it
> manually. Is this bad? Is this typically what people use autogen.sh for o=
r
> should I rename this script something else like post_cvs_checkout.sh?  If=
 I
> make a small change to the configure.ac file, I do call autoreconf direct=
ly,
> the autogen.sh is just for post cvs setup.  If this is still wrong, then =
of
> course I'll remove it, I'm just curious.
Well, instead of running autogen - just run autoreconf. If you change
configure.ac - run autoreconf, if you ammend any of Makefile.am - run
autoreconf, etc... You check out its man page - there is nothing
complicate there.

There is just no need to maintain autogen anymore - autoreconf does this jo=
b.
Rule of thumb - If you've changed anything about autotools - run autoreconf=
 :)



>
> Thanks again for you help, and for answering my questions which are proba=
bly
> pretty naive.
Your welcome :) If you have any other questions - just shoot :)
>
>                  -Pete
>
>
> On 3/4/06, Hai Zaar < ha...@gm...> wrote:
> >
> Hi!
>
> After applying the patch:
> 1. libprojectM - configure now has to bes sounds like  run as follows:
>
>       ./configure --prefix=3D/usr --sysconfdir=3D/etc
>     If you omit sysconfdir parameter, configuration will be installed
> to /usr/etc/projectM and
>     not /etc/projectM as is generally expected.
> 2. autogen.sh is an old school - do _not_ use it. autoreconf command
> is intended to replace
>     autogen scripts.
>
> Now, after applying patch and recompiling/installing libprojectM, lets
> see what to do with xmm-projectM:
> The patch updates xmm-projectM/configure.ac, so after running
> autoreconf && configure, look at the config.h file. You'll see some
> macros defined there. You are particularly interested in:
> PROJECTM_DATADIR
> PROJECTM_SYSCONFDIR
> Their values are picked up by configure from pkg-config database.
>
> So wherever you need to know config/presets file locations, you do
> something like this:
> 1. Include config.h file in the following way:
>      #if HAVE_CONFIG_H
>      #include <config.h>
>      #endif
> 2. Now you have access to those macros, and the rest is trivial C
> coding, which I prefer to leave up to you. Instead of
> if ((in =3D fopen("/etc/projectM/config", "r")) !=3D 0)....
> you do:
> #define CONFIG_FILE "/config"
> char projectM_config[PATH_MAX];
> strcpy(projectM_config, PROJECTM_SYSCONFDIR);
>  strcpy(projectM_config+strlen(PROJECTM_SYSCONFDIR),
> CONFIG_FILE);
> projectM_config[strlen(PROJECTM_SYSCONFDIR)+strlen(CONFIG_FILE)]=3D'\0';
> if ((in =3D fopen(projectM_config, "r")) !=3D 0) .....
>
>
> --
>  Zaar
>
>
>
>


--
Zaar


--
Zaar