Hi all,

I've added three build targets to the SConstruct file.  They are:

install-executables
    installs csound executable and utilities to /usr/local/bin

install-opcodes
    installs plugin opcodes to /usr/local/share/csound/opcodes

install
    calls install-executables and install-opcodes

and you would call these by:

scons install-executables
scons install-opcodes
scons install

The added code is at the bottom of the SConstruct file.  I am still 
working out the best way to include the CsoundVST stuff, how to go about 
doing the library and header files, as well as the best way to override 
the default installation directories.  Any suggestions and tests of 
these targets very much appreciated!

steven

steven yi  writes:

> Hi all,
> 
> I've added three build targets to the SConstruct file.  They are:
...
> install-opcodes
>     installs plugin opcodes to /usr/local/share/csound/opcodes

I'm concerned about putting opcodes in a share directory.  Share
directories contain architecture independent information, such as info
files and say, Python byte code files, but not executable binary
files.  Aren't opcodes binary?  If so, opcodes go in libexec, in GNU
Build System speak. 

John

Hi John,

I wasn't sure where exactly the opcode plugins should go so I put them 
there.  Where does libexec generally point to?  Hmm... I took a look at 
gimp and it seems to have it's files in /usr/lib/gimp.  I'll change the 
opcodes to install to /usr/local/lib/csound/opcodes in just a moment. 
(Does that sound right?)

Also, for the install, does it seem appropriate then to install the 
csound.pdf into "/usr/share/csound/doc"?

(BTW: I notice that pd seems to have everything installed into 
/usr/lib/pd on my system.  Would that be more suitable then to install 
csound executables into /usr/local/bin and then everything else below 
/usr/local/lib/csound ?)

Thanks,
steven


John D. Ramsdell wrote:

>steven yi  writes:
>
>  
>
>>Hi all,
>>
>>I've added three build targets to the SConstruct file.  They are:
>>    
>>
>...
>  
>
>>install-opcodes
>>    installs plugin opcodes to /usr/local/share/csound/opcodes
>>    
>>
>
>I'm concerned about putting opcodes in a share directory.  Share
>directories contain architecture independent information, such as info
>files and say, Python byte code files, but not executable binary
>files.  Aren't opcodes binary?  If so, opcodes go in libexec, in GNU
>Build System speak. 
>
>John
>
>
>
>  
>

Alright, so current I've changed the SConstruct file so that 
install-opcodes installs to /usr/local/lib/csound/opcodes.  Also, the 
SConstruct file now has an added argument option of "prefix" to change 
the base directory of the install, default to /usr/local. 

So, running:

scons install

will install opcodes into "/usr/local/lib/csound/opcodes" and 
executables into "/usr/local/bin".

Running:

scons prefix=/usr install

will install opcodes int "/usr/lib/csound/opcodes" and executables into 
"/usr/bin".

Let me know if there's anything else that's off and I'll make changes. 

Thanks!
steven

steven yi  writes:

> Hi John,
> 
> I wasn't sure where exactly the opcode plugins should go so I put them
> there.  Where does libexec generally point to?  ...

For a package with the name csound5, automake generates Makefiles with
the following definitions:

exec_prefix = ${prefix}

bindir = ${exec_prefix}/bin
sbindir = ${exec_prefix}/sbin
libexecdir = ${exec_prefix}/libexec
datadir = ${prefix}/share
sysconfdir = ${prefix}/etc
sharedstatedir = ${prefix}/com
localstatedir = ${prefix}/var
libdir = ${exec_prefix}/lib
infodir = ${prefix}/info
mandir = ${prefix}/man
includedir = ${prefix}/include
pkgdatadir = $(datadir)/csound5
pkglibdir = $(libdir)/csound5
pkgincludedir = $(includedir)/csound5

With these definitions, you can support multiple architectures by using
the definition:

exec_prefix = ${prefix}/$(arch)

For each arch to be installed.

You should put header files in $(pkgincludedir), documentation often
goes into $(pkgdatadir), and dynamically loaded opcodes go in
$(pkglibdir).  The directory $(libexecdir) is where executable go that
are only invoked by library code.  I think I said this directory was a
good place for opcodes, but I was wrong.

Once again, this is what automake does, but I'm not sure how universal
these definitions are.

John

Hi John,

Thanks very much for this information.  I think the SConstruct file as I 
have it in the last version pretty much goes along with this directory 
organization.  The one thing I am doing, however, is installing into 
/usr/local/lib/csound and not /usr/local/lib/csound5.  What would 
everyone prefer?

Thanks,
steven



John D. Ramsdell wrote:

>For a package with the name csound5, automake generates Makefiles with
>the following definitions:
>
>exec_prefix = ${prefix}
>
>bindir = ${exec_prefix}/bin
>sbindir = ${exec_prefix}/sbin
>libexecdir = ${exec_prefix}/libexec
>datadir = ${prefix}/share
>sysconfdir = ${prefix}/etc
>sharedstatedir = ${prefix}/com
>localstatedir = ${prefix}/var
>libdir = ${exec_prefix}/lib
>infodir = ${prefix}/info
>mandir = ${prefix}/man
>includedir = ${prefix}/include
>pkgdatadir = $(datadir)/csound5
>pkglibdir = $(libdir)/csound5
>pkgincludedir = $(includedir)/csound5
>
>With these definitions, you can support multiple architectures by using
>the definition:
>
>exec_prefix = ${prefix}/$(arch)
>
>For each arch to be installed.
>
>You should put header files in $(pkgincludedir), documentation often
>goes into $(pkgdatadir), and dynamically loaded opcodes go in
>$(pkglibdir).  The directory $(libexecdir) is where executable go that
>are only invoked by library code.  I think I said this directory was a
>good place for opcodes, but I was wrong.
>
>Once again, this is what automake does, but I'm not sure how universal
>these definitions are.
>
>John
>
>
>
>  
>