What you have done sounds very good so far.

But why does Debian insist on installing Lua when Lua can be a part of the Csound distribution and go into the Csound bin directory? Lua is quite small.

If that won't work, it should be easy to create a separate shared library for the Lua interface, but then it will have to get a new name -- something I did not want to do.

Finally, in principle, you could modify SConstruct with new build options (install-lua, install-python, etc.). SConstruct could then test these options and decide whether certain files go into the install target. You could then run scons once to build everything, then run it again and again with different build options and directories to create different package directories.

Regards,
Mike

-----Original Message-----
>From: Felipe Sateler 
>Sent: Aug 16, 2007 11:59 AM
>To: csound-devel@lists.sourceforge.net
>Subject: Re: [Cs-dev] Interfaces building
>
>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
>https://lists.sourceforge.net/lists/listinfo/csound-devel




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