Hi All,

I was thinking we should install headers into "csound" or "csound6"
instead of the base install dir for includes.  i.e. we'd have
/usr/local/include/csound6 and code would have:

#include 

Another issue though, with OSX frameworks, when you use "-framework
CsoundLib64", you're supposed to use  for the
include.  I think we usually get around it by including the
CsoundLib64.framework/Headers directly onto the include path, which is
fine as it gets around the framework design and is a bit more
cross-platform.

My thought here with adding a csound6/ prefix is that it is a bit
tidier when we install as all the headers are grouped together.  Also,
developers can compile applications to work with both Csound5 and
Csound6 installed on the same system if they are separated. (Cs5 could
just remain where it currently is in the base include dir).

Thoughts?
steven

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

FWIW, in debian I install in /usr/include/csound.

I believe it is the job of the build tools to find out where things
are installed. Therefore, a frontend should add -I/usr/include/csound
to the compiler. The install location could probably be retrieved from
pkg-config, or manually by the user. Then just #include .

By not making any promise about where stuff is installed, there can be
any number of parallel installations.

On Tue, May 15, 2012 at 1:49 PM, Steven Yi  wrote:
> Hi All,
>
> I was thinking we should install headers into "csound" or "csound6"
> instead of the base install dir for includes.  i.e. we'd have
> /usr/local/include/csound6 and code would have:
>
> #include 
>
> Another issue though, with OSX frameworks, when you use "-framework
> CsoundLib64", you're supposed to use  for the
> include.  I think we usually get around it by including the
> CsoundLib64.framework/Headers directly onto the include path, which is
> fine as it gets around the framework design and is a bit more
> cross-platform.
>
> My thought here with adding a csound6/ prefix is that it is a bit
> tidier when we install as all the headers are grouped together.  Also,
> developers can compile applications to work with both Csound5 and
> Csound6 installed on the same system if they are separated. (Cs5 could
> just remain where it currently is in the base include dir).
>
> Thoughts?
> steven
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lis

Ah, I see now that you have already coded it to installed to
"include/csound" in the H/CMakeLists.txt and main CMakeLists.txt.  I'm
working on the OSX Framework stuff now and am figuring out best way to
handle the headers (on build or on install).

Any thoughts on csound vs. csound6 (i.e. /usr/include/csound6)?  I'm
still thinking we're going to have a transition period where cs5 and
cs6 apps are going to both need to be supported for building.

Thanks!
steven

On Tue, May 15, 2012 at 2:07 PM, Felipe Sateler  wrote:
> FWIW, in debian I install in /usr/include/csound.
>
> I believe it is the job of the build tools to find out where things
> are installed. Therefore, a frontend should add -I/usr/include/csound
> to the compiler. The install location could probably be retrieved from
> pkg-config, or manually by the user. Then just #include .
>
> By not making any promise about where stuff is installed, there can be
> any number of parallel installations.
>
> On Tue, May 15, 2012 at 1:49 PM, Steven Yi  wrote:
>> Hi All,
>>
>> I was thinking we should install headers into "csound" or "csound6"
>> instead of the base install dir for includes.  i.e. we'd have
>> /usr/local/include/csound6 and code would have:
>>
>> #include 
>>
>> Another issue though, with OSX frameworks, when you use "-framework
>> CsoundLib64", you're supposed to use  for the
>> include.  I think we usually get around it by including the
>> CsoundLib64.framework/Headers directly onto the include path, which is
>> fine as it gets around the framework design and is a bit more
>> cross-platform.
>>
>> My thought here with adding a csound6/ prefix is that it is a bit
>> tidier when we install as all the headers are grouped together.  Also,
>> developers can compile applications to work with both Csound5 and
>> Csound6 installed on the same system if they are separated. (Cs5 could
>> just remain where it currently is in the base include dir).
>>
>> Thoughts?
>> steven
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes, it makes sense to install by default to csound6 to avoid
conflicts with csound5. But I think apps should still just #include
 and manipulate the compiler search path.


On Tue, May 15, 2012 at 3:46 PM, Steven Yi  wrote:
> Ah, I see now that you have already coded it to installed to
> "include/csound" in the H/CMakeLists.txt and main CMakeLists.txt.  I'm
> working on the OSX Framework stuff now and am figuring out best way to
> handle the headers (on build or on install).
>
> Any thoughts on csound vs. csound6 (i.e. /usr/include/csound6)?  I'm
> still thinking we're going to have a transition period where cs5 and
> cs6 apps are going to both need to be supported for building.
>
> Thanks!
> steven
>
> On Tue, May 15, 2012 at 2:07 PM, Felipe Sateler  wrote:
>> FWIW, in debian I install in /usr/include/csound.
>>
>> I believe it is the job of the build tools to find out where things
>> are installed. Therefore, a frontend should add -I/usr/include/csound
>> to the compiler. The install location could probably be retrieved from
>> pkg-config, or manually by the user. Then just #include .
>>
>> By not making any promise about where stuff is installed, there can be
>> any number of parallel installations.
>>
>> On Tue, May 15, 2012 at 1:49 PM, Steven Yi  wrote:
>>> Hi All,
>>>
>>> I was thinking we should install headers into "csound" or "csound6"
>>> instead of the base install dir for includes.  i.e. we'd have
>>> /usr/local/include/csound6 and code would have:
>>>
>>> #include 
>>>
>>> Another issue though, with OSX frameworks, when you use "-framework
>>> CsoundLib64", you're supposed to use  for the
>>> include.  I think we usually get around it by including the
>>> CsoundLib64.framework/Headers directly onto the include path, which is
>>> fine as it gets around the framework design and is a bit more
>>> cross-platform.
>>>
>>> My thought here with adding a csound6/ prefix is that it is a bit
>>> tidier when we install as all the headers are grouped together.  Also,
>>> developers can compile applications to work with both Csound5 and
>>> Csound6 installed on the same system if they are separated. (Cs5 could
>>> just remain where it currently is in the base include dir).
>>>
>>> Thoughts?
>>> steven
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-deve

I have seen the following pattern which seems to simplify things to me:

In /usr/local/include there is a csound dir.
In the csound dir there is a versioned csound dir.
I.e. we have /usr/local/incude/csound/csound6 and
/usr/local/include/csound/csound6
Then to include headers, we can have "#include
" and it just works off /usr/local/include,
or we can have "#include " but the build has to be
configured to look in /usr/local/csound/csound6.

Regards,
Mike

On Tue, May 15, 2012 at 3:54 PM, Felipe Sateler  wrote:
> Yes, it makes sense to install by default to csound6 to avoid
> conflicts with csound5. But I think apps should still just #include
>  and manipulate the compiler search path.
>
>
> On Tue, May 15, 2012 at 3:46 PM, Steven Yi  wrote:
>> Ah, I see now that you have already coded it to installed to
>> "include/csound" in the H/CMakeLists.txt and main CMakeLists.txt.  I'm
>> working on the OSX Framework stuff now and am figuring out best way to
>> handle the headers (on build or on install).
>>
>> Any thoughts on csound vs. csound6 (i.e. /usr/include/csound6)?  I'm
>> still thinking we're going to have a transition period where cs5 and
>> cs6 apps are going to both need to be supported for building.
>>
>> Thanks!
>> steven
>>
>> On Tue, May 15, 2012 at 2:07 PM, Felipe Sateler  wrote:
>>> FWIW, in debian I install in /usr/include/csound.
>>>
>>> I believe it is the job of the build tools to find out where things
>>> are installed. Therefore, a frontend should add -I/usr/include/csound
>>> to the compiler. The install location could probably be retrieved from
>>> pkg-config, or manually by the user. Then just #include .
>>>
>>> By not making any promise about where stuff is installed, there can be
>>> any number of parallel installations.
>>>
>>> On Tue, May 15, 2012 at 1:49 PM, Steven Yi  wrote:
>>>> Hi All,
>>>>
>>>> I was thinking we should install headers into "csound" or "csound6"
>>>> instead of the base install dir for includes.  i.e. we'd have
>>>> /usr/local/include/csound6 and code would have:
>>>>
>>>> #include 
>>>>
>>>> Another issue though, with OSX frameworks, when you use "-framework
>>>> CsoundLib64", you're supposed to use  for the
>>>> include.  I think we usually get around it by including the
>>>> CsoundLib64.framework/Headers directly onto the include path, which is
>>>> fine as it gets around the framework design and is a bit more
>>>> cross-platform.
>>>>
>>>> My thought here with adding a csound6/ prefix is that it is a bit
>>>> tidier when we install as all the headers are grouped together.  Also,
>>>> developers can compile applications to work with both Csound5 and
>>>> Csound6 installed on the same system if they are separated. (Cs5 could
>>>> just remain where it currently is in the base include dir).
>>>>
>>>> Thoughts?
>>>> steven
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Okay.  Compiler search path and  sounds good too.

On Tue, May 15, 2012 at 3:54 PM, Felipe Sateler  wrote:
> Yes, it makes sense to install by default to csound6 to avoid
> conflicts with csound5. But I think apps should still just #include
>  and manipulate the compiler search path.
>
>
> On Tue, May 15, 2012 at 3:46 PM, Steven Yi  wrote:
>> Ah, I see now that you have already coded it to installed to
>> "include/csound" in the H/CMakeLists.txt and main CMakeLists.txt.  I'm
>> working on the OSX Framework stuff now and am figuring out best way to
>> handle the headers (on build or on install).
>>
>> Any thoughts on csound vs. csound6 (i.e. /usr/include/csound6)?  I'm
>> still thinking we're going to have a transition period where cs5 and
>> cs6 apps are going to both need to be supported for building.
>>
>> Thanks!
>> steven
>>
>> On Tue, May 15, 2012 at 2:07 PM, Felipe Sateler  wrote:
>>> FWIW, in debian I install in /usr/include/csound.
>>>
>>> I believe it is the job of the build tools to find out where things
>>> are installed. Therefore, a frontend should add -I/usr/include/csound
>>> to the compiler. The install location could probably be retrieved from
>>> pkg-config, or manually by the user. Then just #include .
>>>
>>> By not making any promise about where stuff is installed, there can be
>>> any number of parallel installations.
>>>
>>> On Tue, May 15, 2012 at 1:49 PM, Steven Yi  wrote:
>>>> Hi All,
>>>>
>>>> I was thinking we should install headers into "csound" or "csound6"
>>>> instead of the base install dir for includes.  i.e. we'd have
>>>> /usr/local/include/csound6 and code would have:
>>>>
>>>> #include 
>>>>
>>>> Another issue though, with OSX frameworks, when you use "-framework
>>>> CsoundLib64", you're supposed to use  for the
>>>> include.  I think we usually get around it by including the
>>>> CsoundLib64.framework/Headers directly onto the include path, which is
>>>> fine as it gets around the framework design and is a bit more
>>>> cross-platform.
>>>>
>>>> My thought here with adding a csound6/ prefix is that it is a bit
>>>> tidier when we install as all the headers are grouped together.  Also,
>>>> developers can compile applications to work with both Csound5 and
>>>> Csound6 installed on the same system if they are separated. (Cs5 could
>>>> just remain where it currently is in the base include dir).
>>>>
>>>> Thoughts?
>>>> steven
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net