[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