Hi Istvan,

On 11/8/05, Istvan Varga <istvan_v@fibermail.hu> wrote:
> Steven Yi wrote:
> So, I would have to type src/Opcodes/oscbnk.c instead of just
> Opcodes/oscbnk.c (and so on with all the other source files)
> all the time,

Yes. With tab completion on linux and vim, I don't see that as such a
big obstacle. But if I am not thinking of a use case, let me know.

and it would no longer be possible to just run
> the development build from the top level directory without
> setting OPCODEDIR (as all binaries are moved to build/32 or
> whatever else) ? That is rather inconvenient.

No, this is incorrect.  All the binaries for the first phase would
remain generated in the current directory as it is now.  Only the
object files would be generated in build/32. This isn't a satisfactory
solution as it allows only having one set of generated binaries at a
time, but it is a first step. One would have to then erase all
binaries and then rebuild with 64 or 32, and the binaries can be
quickly built using object files which are in sync and only compiling
those which would be necessary.

I'd like to eventually have the plugins generated to a plugins and
plugins64 folder to keep the separated, as you have it in your RPM
script (makes sense to me).

The use case I was expecting to do for myself would be to set
OPCODEDIR and OPCODEDIR64 to the dev plugins and plugins64 directories
(to be introduced in a phase two) in my user account, and set to
/usr/local/lib/csound/plugins and /usr/local/lib/csound/plugins64 in
my root account, which I normally run Csound for general use.

> > It should also make building files for distribution easier
> > (installers, RPM's, .debs, etc.) in my opinion.
>
> Not really. In fact, it would break my package generator script
> which would need to be updated.

The end goal would be to generate the structure you generate by hand
in your script, i.e.:

target/
  bin
  lib
  plugins
  plugins64
  H

That is the end goal at least.  The RPM script then wouldn't require
much for building all of the different versions and wouldn't have to
build it outside of the buildroot.  For this first phase, since your
generator script calls scons for everything except for copying the
header files and the plugins would be generated to the top directory
as they have been, the only required change for your script would be
to prepend "src/" to the headers array, which can be done with one
line of code using a python list comprehension:

headerFiles = [ "src/" + f for f in headerFiles]

(The above is what I am similarly planning for the SConstruct file)

The package generator script isn't very long either, and I would be
willing to ensure that is working as well.


Thinking about it, we could make things a little simpler to if we were
to generate all opcode plugins using libxxxx64.so naming.  It would be
easier to see from the directory what is a 32 and what is a 64
library.  I like how executables have that distinction already.  What
would everyone think about that? That alone may remove the need for a
phase two target structure I think.

steven


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net