Csound Csound-dev Csound-tekno Search About

Re: [Cs-dev] Interfaces building

Date2007-08-15 22:44
FromMichael Gogins
SubjectRe: [Cs-dev] Interfaces building
That sounds bad, but perhaps it's not really so bad. If we are talking about a purely binary/header files/libraries installation, without the Csound source code, we may not need to change SConstruct at all. 

I know that for Java, there is no binary dependency, all Java native interface code is generated by the compiler from the Java header files, so the Java interface library is not linked with any Java binary. Java itself will dlopen the Csound interface library and call into it. So for a non-Java package, you can simply omit all .java and .class and .jar files from the package.

The situation may well be the same for Python. Currrently the actual Python extension is a .pyd shared library. I do not think there is any binary dependency from any Csound program or .so to Python. If that is so, then for a non-Python package, you can simply omit all .py, .pyc, and .pyd files from the package. But to make sure, use nm on the Csound .so files and make sure they do not reference any Py functions.

For Lua, I would just go ahead and install the Lua binaries locally in all cases. They are very small and have no external dependencies of their own. This is what I already do in Windows.

If we do need to modify SConstruct, I can do that, but it is pretty easy. You can just make a copy of an environment and add libraries to the copy and use that to build targets (newEnvironment = oldEnvironment.Copy()).

I am glad to see you are helping us with this.

Regards,
Mike


-----Original Message-----
>From: Felipe Sateler 
>Sent: Aug 15, 2007 5:02 PM
>To: csound-devel@lists.sourceforge.net
>Subject: [Cs-dev] Interfaces building
>
>I just noticed that there is a common environment for building the
>interfaces in SConstruct. The result is that all interface libraries are
>built with the same build flags, which means that the lua interface library
>is linked with python, for example. This usually is not a problem, because
>one would install all built interfaces on the system.
>However, for a Debian package, I need to be able to provide separate
>packages for the different interfaces, which should be installable
>independently. The problem is that, as (for example) the python interface
>library is linked to the lua core libraries, a person would need to install
>lua to use the python interface[1]. This doesn't make much sense. 
>The solution is, of course, creating separate environments for the different
>interfaces. However I'm not proficient with neither python nor SCons, and I
>don't know well how the csound build system works, so I don't know where to
>start to do that.
>
>[1] This is due to debian's automatic dependency handling: a package
>automatically depends on the correct version of all linked libraries.
>
>-- 
>
>  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