[PD-dev] installation paths

[guenter geiger]

On Mon, 2 Feb 2004, d.lj wrote:
> 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.

I think a common build system for all platforms (where the developers
just have to drop in their external) and some basic guideline how to
do it would not necessarily be restrictive.

It would rather help the developers. They just would not need to think
about the build system anymore, and if something in the install paths
changes (e.g. we decide to split the externals in subdirectories) it
would happen in an organized way and easy to communicate to users.

Guenter
















>
> 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
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
>