[PD-dev] installation paths

Hans-Christoph Steiner hans at eds.org
Thu Feb 12 18:11:52 CET 2004 

On Sun, 8 Feb 2004, guenter geiger wrote:
> 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).

Yes, I think it would be great if all of the externals people used the
same build system.  But many do not, and there are other things, like
xgui, gripd, etc. which does seem to fit into the externals
tree.  Currently the build system has been created by a handful of
maintainers basically, but I think if we document it well enough, then
external-developers will do the work themselves.
 
> 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.

Yeah, this is exactly what I am was trying to say, but I guess not so
clearly.  This is a basic specification for an  'interface' to the
externals build system.

 
> >
> > 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 ?

Flext has a bunch of READMEs and license files, GEM has its own manuals,
tutorials, etc.  It would be nice to have all this stuff organized so that
people can find it.  Right now, the organization is very rough.  For
example, "7.stuff" doesn't really tell yo much about what's in there and
"6.externs" only has the really basic writing-externals objects.

.hc


 
> > 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
> >
> 

	zen
	   \
	    \
	     \

More information about the Pd-dev mailing list