On Thursday 01 December 2005 12:01, jpff@codemist.co.uk wrote: > In bin at present i have: > brkpt cs csb64enc cscore > csound cstclsh cswish cvanal > dnoise envext extract extractor > het_export het_import hetro linseg > lpanal lpc_export lpc_import makecsd > mixer pvanal pvlook scale > scot scsort sdif2ad srconv > tabdes > > QUESTION: SHOULD ANY OF THESE NOT BE DISTRIBUTED? While these are fine, if you intend to distribute binaries that statically link against the Csound library, then all utilities that can be called with csound -U could be replaced with simple wrappers, allowing for a much smaller package. > QUESTION: WHAT OTHER BASIC BINARIES ARE THERE? > > In the opc I expect all the lib.so/dynlib plugins we compile. It is incorrect to assume that all dynamic libraries are plugins. Important exceptions include libcsound.so.5.1, libcsound64.so.5.1, lib_csnd.so, _csnd.so, and tclcsound.so; that is, of course, assuming that you want to distribute these. Other files that should be noted are csoundapi~.pd_linux and csnd.py. > Personally I am disappointed to see the collection of a number of > them into a larger library, as it conflicts with my view of small lean > tuned performance systems, but I can live with the majority view As very few people would want to load dozens of small plugins separately, it makes sense to collect all the basic "standard" opcodes (that do not have external dependencies other than libsndfile, are written in C, and use no statics) in a single library that is still not too large (~400k). Most of the bloat comes from plugins that depend on large external libraries, such as FLTK or Python, so if you load just libstdopcod.so and nothing else, you have most opcodes while still having a "lean tuned performance system". Also, loading a single library is faster and uses less memory than the more than 50 separate plugins it replaces. > QUESTION: ARE THERE ANY PLUGINS WE SHOULD NOT DISTRIBUTE? I am not sure why any of the plugins should be excluded, unless it is particularly difficult to build (i.e. arcane dependencies) or has legal problems (I am still uncertain about the liblo GPL issue). > The documentation I am assuming is the HTML version of the manual, > which is looking almost complete now. > > QUESTION: SHOULD WE DISTRIBUTE PDF PS OR DOC MANUALS? The HTML manual should be fine, there is no need to include the same documentation more than once. Of course, documentation in special formats can be made available as a separate download. > My largest uncertainty is regarding the libraries. We should not > overwrite existing installed libraries, but checking this is a pain. > At present I am rather hand writing this area, but there is a > possibility for a more table-driven installation here. If you rely on wrappers, then it can be an option to install the libraries to a separate "private" directory, and have the wrapper set LD_LIBRARY_PATH to that directory. Also, the libraries may be linked statically, and some of them may be available as part of the standard package repository of the distribution (ALSA, Jack, and libsndfile should be available, and fluidsynth is often included, too). Libraries that should be distributed with the package or statically linked include FLTK (it is usually part of a Linux distribution, but almost always compiled without --enable-threads; that should be fixed by compiling Csound with noFLTKThreads=1, though), PortMidi (it is rarely used and not well known), liblo (rarely used and often too old), and PortAudio (included sometimes, but tends to be too old). Also, we can get rid of the PortMusic libraries, and make ALSA the default instead; that limits the special libraries to liblo, FLTK (unless noFLTKThreads=1 is used), and maybe fluidsynth. > The last topic is dealing with the OPCODEDIR environment. We could > tell the user to set the environment correctly, but experience on the > Csound list is this is not easy. I favour wrapping the installed > binaries with a script to set environments, possibly in two bin > directories -- eg wrapped in /usr/local/bin and unwrapped in > /usr/local/bib/CS5. I also made it possible to use a fixed path defined in Top/csmodule.c (depending on MYFLT and word size) as the default when OPCODEDIR is not set, instead of the current directory that does not make much sense in the case of a package that is going to be installed. That does not work with a relocatable package (such as your GUI installer), though, but is useful for an RPM distribution that is always installed to the same location. > QUESTION: SHOULD WE USE ALL WRAPPERS? What do you mean by that ? > QUESTION: WHICH ENVIRONMENT VARIABLES SHOULD WE DEFINE IN THE > WRAPPED? OPCODEDIR, OPCODEDIR64 (should be obvious) LD_LIBRARY_PATH (if additional shared libraries are installed, like FLTK, liblo, etc.) CSSTRNGS (optional, directory containing .xmg files) By the way, did you have a look at my package builder scripts ? They already have to deal with many of the above issues. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net