This is easiest now, but I really don't think this should be the recommended way to do it. I would prefer the development model to be like any other Linux package. Ideally, this is what I am imagining: csound5.rpm - all binary utilities csound5-src.rpm - src rpm release csound5-devel.rpm - all headers You can install those, and after that the user would have everything they would need to run csound as well as compile a csound host or opcode. The user, IMO, should not ever have to touch SConstruct file that comes with Csound, let alone know anything about it. They should only need to know the API and the csound.h and csdl.h headers. They should be free to use whatever dev environment the would like for compiling their opcode library (for instance, I'd rather use Eclipse's C Development environment and use the managed make mode for creating an opcode plugin, rather than write a makefile). I think that would make it easiest for users to develop against csound, IMO. I've done a simple opcode port to cs5 using a simple Makefile and using an #include header and it was *much* simpler than dealing with learning SConstruct and all that. steven On 8/17/05, Michael Gogins wrote: > The easiest way to do this is to use the existing SConstruct file and modify it -- add your app or plugin as a new target. You can copy the SCons code for an existing plugin opcode to make a new plugin opcode, copy the CsoundVST SCsons code or csound_main SCons code to make a new host application using Csound, etc. The SCons code will know the macros. > > There may, I vaguely recall, be a way to write a new SConstruct that can read the existing one for the environment... I'll look into that.... > > Regards, > Mike > > -----Original Message----- > From: Steven Yi > Sent: Aug 17, 2005 1:58 PM > To: csound-devel@lists.sourceforge.net > Subject: Re: [Cs-dev] csound.h > > Hi All, > > Thanks all for chiming in with comments. I think having the csound.h > and csdl.h is fine, just would like to get the opcode and host > developer roles more clearly defined so that some SDK's could start > being made with detailed instructions. Having only the required > headers installed for development is a big plus to making the point of > entry for developing against Csound lower, I think. > > Also, certain macros need to be defined for those headers to work out > correctly, yes? If I am building a separate application, what's the > best way to convey those macros which need to be defined? > > steven > > On 8/17/05, Istvan Varga wrote: > > Michael Gogins wrote: > > > > > By the way, CsoundVST with latest CVS sources is building and > > > working. I only had to make one minor change (the output soundfile > > > name is now being blanked out after csound finishes running so I have > > > to save it in CsoundVST after compiling). So, thanks for your > > > attention to CsoundVST when changing the ENVIRON to CSOUND. > > > > I made a number of changes to CsoundVST sources to fix compile > > errors, although the main issue was not the renaming of ENVIRON to > > CSOUND (this was done with a simple program that was run on all source > > files), but the replacement of void* instance pointers with ENVIRON* > > (now CSOUND*) and some of the header changes. > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > > _______________________________________________ > > Csound-devel mailing list > > Csound-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net