| Michael Gogins wrote:
> I checked, and there are a few binary links between csnd.so and Python.
> But I believe these can easily be removed.
Good :)
> In any case, I think the best way to make packages for Debian is to use
> the install target in SConstruct, and not an external script. The install
> target, if done properly, will pick up only what is appropriate from the
> build options. In other words, if you build the Python interface, the
> install target will get a copy of csnd.so that contains the Python
> interface. If you do not build the Python interface, csnd.so will not
> contain any Python linkages.
I do use the install target in scons. However, from one build I need to
provide all interfaces, and I would like to provide separate packages for
each interface. That way, a person installing, eg, the python interface
won't get the useless (to him) lua and java interfaces. If the python
interface links with liblua*.so (which currently does, because of the
common environment), the automatic dependency handler of Debian will force
installation of liblua when installing the python interface library,
*independently of wether the interface actually uses the library or not*.
>
> This is because SConstruct has conditional code for building different
> configurations of the source code, depending on the platform, build tools,
> and command-line build options.
>
> The install target has not been maintained. Basically,
> environment.Install() should get every target that is built, plus the
> header files and any local third-party binaries (such as Lua) that we want
> to distribute.
I see this is not always the case: for example the python interface is not
installed. It should be trivial to implement installation following what
you wrote about the install functions, though.
> Then when you run "scons install", you will get a
> directory tree containing all the stuff that you want to go into the
> Debian package for that build configuration.
Just to clarify, a single source package (csound) can produce several binary
packages. Splitting is actually encouraged/"required" for non-trivial
packages, for several reasons:
1. A user may want to install one part of the package, but not another.
2. The automatic dependency handler will force installation of several
dependencies which may not be needed for the user's need (for example,
I may want to install csound but not the GUIs, so if there is a proper
package separation one could avoid installing tcl/tk).
3. If the package includes libraries, it would be possible to upload a
third party package which only uses the library without the need of
the entire csound environment.
So in the end, from one build there are several binary packages produced.
The actual procedure I use for building packages is the following:
1. Build the source
2. Install into debian/tmp directory (we get, then: debian/tmp/usr/*)
3. Move stuff around to comply with Debian Policy (eg: JNI wrappers need
to live in /usr/lib/jni, not /usr/lib), to avoid name conflicts and
any other reason one could have.
4. Build the different packages according to files called
.install which tell which files go in which binary
package.
Right now I have the following packages done:
1. csound (work in progress, currently contains everything that doesn't go
anywhere else. Should contain the command-line binaries)
2. libcsound64-5 (contains the shared library, compiled with double
precision)
3. libcsnd-java (the java interface)
4. libcsound64-dev (the development files)
5. pd-csound (the PureData csound~ opcode)
6. python-csound (The python interface)
So the reason I faced the problem is because python-csound now depends on
liblua${version}, when it shouldn't.
--
Felipe Sateler
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |