> > > 1. Not everyone will want things in these directories. I don't care > > > > I use /usr/local/ for all non-system programs, because of how I set up my > > diskspace. So, I agree, I'd enjoy seeing a bit of flexibility in where the > > program ends up > > My interest is main focused on the updating of Piper. I know this is something > not to be realized soon, but maybe after compiling we can install just the > 'basic' > and have that install the complete system, and have it up to date. I figured CVS was good for the updating of piper. The best solution would be to include detailed CVS instructions for an end-user so they could go thru CVS and have it install new piper on top of old (choosing right directories, etc). Just tell the user in the beginning that they should remember what the directory prefix is for installing piper (/usr or /usr/local). Since most of that stuff is configuable at the configure level, why not just include it as part of the INSTALL file? (ie, "2. Choose the prefix for piper installation by typing (blah blah) --prefix=/usr/local for example. This will be your $PIPERPATH; if you want to update piper later thru CVS, make sure you use the same prefix as this one to avoid version clashes. > > > > non-portable (that's why I'm making Jarl fight with autoconf :-). > > > > I recently tried installing a package that had a hand-written > > Makefile ported from a whole 'nother architecture. What a nightmare. > > Automake is a nightmare too.. but only for one person. I've used handcrafted > makefiles till recently, but I must agree autoconf should be used, or similar > tools. > > bye, > jarl > > > _______________________________________________ > pipet-devel maillist - pipet-devel at bioinformatics.org > http://bioinformatics.org/mailman/listinfo/pipet-devel >