[PD-dev] installation paths

[guenter geiger]

On Fri, 6 Feb 2004, Hans-Christoph Steiner wrote:
> This is definitely the best approach.  Instead of a policy, we could
> define an 'interface' that a developer would need to implement in order
> for their externals to be included in the packages.  For example, in
> order to have your externals included in the MacOS X installer, you
> would need to implement "make pkg", which would compile everything in
> that externals collection and generate a MacOS X package to be included
> in the installer.

Hi, actually thought that the external developers do not provide any build
system whatsoever (I do not know how to create an MacOS X package, so
I would fail to follow your interface).

I was rather thinking to do it in a similar way as the build system.
e.g.

each external provides:
1 c-file with the code
1 .txt file, with an easily parseable description that will be
automatically transformed into online documentation
1 .pd file with the documentation.

A developer drops this into the external pool, then the external gets
automatically compiled on all architectures and results get send to
the uploader.

>
> In order for this to work, there would need to be some standard make
> targets and a standard internal layout for Pd, with $PDDIR being freely
> redefinable (/usr, /usr/local, /Applications, C:\Program Files, etc.).
> Here a suggested internal layout based on what exists:
>
> abstractions
> bin
> doc
> 	0.tutorials/
> 	1.manual/
> 	2.control.examples/
> 	3.audio.examples/
> 	4.fft.examples/
> 	5.reference/
> 	6.externals
> 		flext/
> 		GEM/
> 	7.stuff/
> 	sound/
> extra
> lib (for external libraries)

This seems to be basically ok, although I do not fully understand what the
"flext" and "GEM" entries in 6.externals means. Should this be the place
to put examples ?

> Another thing is to have a suggested file layout for developer's files,
> so that the paths to the pd sources, for example, are the same for
> everyone.  I think most people basically are doing it the same way now,
> but I'll lay it out just for discussion's sake.  I think everything
> should be laid out as if you just run 'cvs checkout' for everything in
> the same dir:
>
> abstractions
> doc
> externals
> packages
> pd
>
> I would ultimately like to see various 'extensions' to pd in this tree
> also, maybe in a directory/cvs module called 'extensions':
>
> extensions
> 	Gem
> 	GemLibs
> 	Framestein
> 	gripd
> 	xgui
> 	etc. etc.
>
> I think the key to making this work with the pd community is not making
> it a 'requirement' for the CVS per se. Instead a developer will have to
> provide the standard interface to the package makers in order for the
> maintainers to include their externals in the packages.  I would love
> to be able to include every piece of software written for Pd in the
> installers, but I do not have time or an inclination to figure out each
> individual build system.  But if someone else wants to include it in
> the build systems themselves, they can.
>
> The other key is providing clear examples and documentation about the
> standard interfaces and path layout.  I am guilty of not doing this yet
> for sure, but I do think its quite important and will start working on
> it while I working making new installers for 0.37-1.
Everything you have done until now was great, and it helps the pd users a
lot.
No reason to feel guilty :)

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
> >>
> >
> >
> > _______________________________________________
> > PD-dev mailing list
> > PD-dev at iem.at
> > http://iem.at/cgi-bin/mailman/listinfo/pd-dev
> >
>
> ________________________________________________________________________
> ____
>
> Man has survived hitherto because he was too ignorant to know how to
> realize his wishes.
> Now that he can realize them, he must either change them, or perish.
> 		                                     -William Carlos Williams
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
>