On Sun, 1 Feb 2004, Larry Troxler wrote:
not many/all externals (like my own) do this though if they have a configure script or install target at all so you have to edit the makefile. could def. be improved.
One of the goals of the CVS was to have a common structure w/ makefiles and common places. There are other more subtile problems in several of the makefiles of the externals, like not using -fPIC etc, problems of compilation on some architectures, libraries etc.
One attempt to solve this was the build/<arch> structure that is in CVS, but I am not really happy with that, and it only works partly. I can't think of a better solution, well not unless the developers start to work closer together, which would mean more communication overhead.
The places the externals get installed to currently (/usr/lib and /usr/local/lib) are the official places of the FHS, the Filesystem Hierarchy Standard (see http://www.pathname.com/fhs/), which among other things says that locally compiled packages should go into /usr/local, whereas packages that come with the distribution go into the /usr tree.
I suggest that we put all the externals and libraries in ../lib/pd/extra. Of course we have to resolve the name conflicts then, which would be a good idea in general.
After all we have to put more administrative work into the CVS, something I have been trying to do, but I am not very good at it, it's just too boring ... (well, thats probably why only a few of the developers show interest for these problems, some are downright fighting each attempt to come up with a common structure .. well, what can we do ? )
Guenter
Hmm, I had thought that this was more than just a choice between /usr/* and /usr/local/*.
Maybe everything's getting sorted out lately, and I just have some really old stuff lying around. Certainly I wouldn't complain about /usr/* vs. /usr/local/* if it were certain what the structure was underneath.
Looking at my .pdrc below, I guess that a lot of makefiles havent't really included "install" targets, or else I didn't bother to use them. Truth to be told, I should prune this thing, and maybe things are getting better and some of these paths are now empty.
But still, remaning suspects are the vasp and iemlib* libraries.
Larry
-path cur -path pd -path pd/util -path pd/test -path pd/ins -path pd/help -path /usr/lib/pd/externs -path /usr/local/lib/pd/externs -path /usr/lib/pd/extra -path /usr/local/lib/pd/extra/vasp/pd -path k_quile -lib xeq/xeq -lib /usr/lib/pd/extra/iemlib1 -lib /usr/lib/pd/extra/iemlib2 -lib vasp/vasp
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev