[PD-dev] installation paths

[d.lj]

[Frank Barknecht]->[Re: [PD-dev] Help search; standard external...

 |Hallo,
 |
 |guenter geiger hat gesagt: // guenter geiger wrote:
 |
 |> 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 ? )
 |
 |We aren't that many as there are maintainers in Debian, but still I
 |think, that this will only get solved at last by having a written
 |policy for externals in CVS, that all developers agree upon and then
 |we could adapt everything to follow that policy.
 |
 |There are some hairy issues involved. For example, packaging would be
 |much easier, if the policy would not allow libraries, but several
 |developers think, that under certain circumstances libraries are a
 |good thing.
 |
 |I think, that the location of externals and help files is rather easy
 |to agree upon. As this is cross-platform development, we need to find
 |a way to abstract out the Pd directory, by, say, using an environment
 |variable PDDIR or a define while building the externals. Then this
 |would specify, where everything goes relative to that setting.

hy all.

i m not sure if such a policy is the key to this dilemma given
guenthers statement of resistance against structuring, since its only
more of structuring, more specifically a top-down structuring and i
think the other way round would be preferable.

the cvs right now fullfils at least the function of a more or less
complete collection spot for externals regardless of the state they're
in, which is pretty good, so exlcuding stuff via some policy will only
generate regress in this aspect. i think the same goes for using
libaries in externals.

a lot of stuff is being created by a devel-user hybrid and commitment
stops if a local solution is achieved, i.e. bringing a little project
into some formal shape is a bunch of work with no more direct benefit.

maybe a proper example external would help here, since a lot of stuff is
being made via copy and pasting from existing externals.

this means that the work fixing makefiles and putting stuff into common
locations is being shifted to those packaging stuff for particular
distribution formats. but exactly the work thats being done there could
be folded back into the cvs?

i dont think that agreeing on any general common location for stuff is
necessary as long as there's a configure script providing a --prefix
option.

furthermore, i dont think its productive to moan about stuff being
strewn all over the place. just have a quick glance over the stuff
you're compiling and you can figure where make install will put it. if
there's no install target at all, its even more your responsibility to
pass in the proper path when doing a cp *.pd_platform /path/to/pd/externs

i do install a lot of externals here and there and somehow i manage to
get them all under /usr/lib/pd and i m not applying any kind of voodoo
or excessively timeconsuming techniques to achieve this, which is not to
say that i dont (massively) appreciate doing "cvs co externals" instead
of clicking 20 plus websites and downloading tar.gz's.

and given that probably most "users" use binary packages anyway its
again back to the responsibility of the package maintainer.

i think this boils down to: if you think you can fix something, fix it
and commit it.

if not, spend money on a commercial package or hire someone to fix it
for you.

make sense?
make: *** No rule to make target `sense'.  Stop.

bst,jdl

-- 
i          x          D          ¥          ·          o          r          G
GPG-key at http://xdv.org/~jdl/jdl.pub.asc