Hi all,

Steven prodded me into updating the config-h feature branch for merge,
and in the process I noticed something that it may be desirable to
avoid:

/home/felipe/src/deb/csound/up/csound6/build/config.h:66:0: warning:
"HAVE_TERMIOS_H" redefined [enabled by default]
 #define HAVE_TERMIOS_H
 ^
In file included from /usr/include/python2.7/pyconfig.h:3:0,
                 from /usr/include/python2.7/Python.h:8,
                 from
/home/felipe/src/deb/csound/up/csound6/build/frontends/CsoundAC/CsoundACPYTHON_wrap.cxx:155:
/usr/include/x86_64-linux-gnu/python2.7/pyconfig.h:823:0: note: this
is the location of the previous definition
 #define HAVE_TERMIOS_H 1
 ^

So, it is probably a bad idea to define stuff in the public namespace
in a file that will be installed and included by others. I see 3
routes out of this:

1. Capability defines should be specified in the commandline. I don't
particularly like this.
2. Split the config.h into a public and an internal part, install only
the public.
3. Protect the internal defines with __BUILDING_LIBCSOUND or other define.

The 3rd option seems the easiest to implement. Would
__BUILDING_LIBCSOUND be appropriate for this use? Or should I define a
new variable __BUILDING_CSOUND that could act as guard? Or should I go
some other route?

-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Felipe,

This seems tricky, as some opcode libraries might depend on a
capability. However, I am not certain what those might be, so we would
need to do research into what's being used where. We need to have some
things be public like MYFLT being double so that API users will
automatically have that set. Other things seem to be really for things
built within the Csound build system as a whole.  My thought would be
to go with route #2 and #3 combined. We could have two headers,
config.h.in and config_private.h.in.  The first would be public always
and #include'able in csound.h.  config_private.h.in might then be
usable when building opcode plugins as well as libcsound.  For opcode
plugins, we'd have to add config_private.h to the list of #includes.

Does that sound good or have I missed something?

Thanks for looking into this!
steven



On Tue, Feb 11, 2014 at 12:46 PM, Felipe Sateler  wrote:
> Hi all,
>
> Steven prodded me into updating the config-h feature branch for merge,
> and in the process I noticed something that it may be desirable to
> avoid:
>
> /home/felipe/src/deb/csound/up/csound6/build/config.h:66:0: warning:
> "HAVE_TERMIOS_H" redefined [enabled by default]
>  #define HAVE_TERMIOS_H
>  ^
> In file included from /usr/include/python2.7/pyconfig.h:3:0,
>                  from /usr/include/python2.7/Python.h:8,
>                  from
> /home/felipe/src/deb/csound/up/csound6/build/frontends/CsoundAC/CsoundACPYTHON_wrap.cxx:155:
> /usr/include/x86_64-linux-gnu/python2.7/pyconfig.h:823:0: note: this
> is the location of the previous definition
>  #define HAVE_TERMIOS_H 1
>  ^
>
> So, it is probably a bad idea to define stuff in the public namespace
> in a file that will be installed and included by others. I see 3
> routes out of this:
>
> 1. Capability defines should be specified in the commandline. I don't
> particularly like this.
> 2. Split the config.h into a public and an internal part, install only
> the public.
> 3. Protect the internal defines with __BUILDING_LIBCSOUND or other define.
>
> The 3rd option seems the easiest to implement. Would
> __BUILDING_LIBCSOUND be appropriate for this use? Or should I define a
> new variable __BUILDING_CSOUND that could act as guard? Or should I go
> some other route?
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

So, you say config.h should say:

#ifdef __BUILDING_LIBCSOUND
 #include "csound_private.h"
#endif


And plugin opcodes include csound_private.h manually? Looks like a
good compromise.




On Tue, Feb 11, 2014 at 5:43 PM, Steven Yi  wrote:
> Hi Felipe,
>
> This seems tricky, as some opcode libraries might depend on a
> capability. However, I am not certain what those might be, so we would
> need to do research into what's being used where. We need to have some
> things be public like MYFLT being double so that API users will
> automatically have that set. Other things seem to be really for things
> built within the Csound build system as a whole.  My thought would be
> to go with route #2 and #3 combined. We could have two headers,
> config.h.in and config_private.h.in.  The first would be public always
> and #include'able in csound.h.  config_private.h.in might then be
> usable when building opcode plugins as well as libcsound.  For opcode
> plugins, we'd have to add config_private.h to the list of #includes.
>
> Does that sound good or have I missed something?
>
> Thanks for looking into this!
> steven
>
>
>
> On Tue, Feb 11, 2014 at 12:46 PM, Felipe Sateler  wrote:
>> Hi all,
>>
>> Steven prodded me into updating the config-h feature branch for merge,
>> and in the process I noticed something that it may be desirable to
>> avoid:
>>
>> /home/felipe/src/deb/csound/up/csound6/build/config.h:66:0: warning:
>> "HAVE_TERMIOS_H" redefined [enabled by default]
>>  #define HAVE_TERMIOS_H
>>  ^
>> In file included from /usr/include/python2.7/pyconfig.h:3:0,
>>                  from /usr/include/python2.7/Python.h:8,
>>                  from
>> /home/felipe/src/deb/csound/up/csound6/build/frontends/CsoundAC/CsoundACPYTHON_wrap.cxx:155:
>> /usr/include/x86_64-linux-gnu/python2.7/pyconfig.h:823:0: note: this
>> is the location of the previous definition
>>  #define HAVE_TERMIOS_H 1
>>  ^
>>
>> So, it is probably a bad idea to define stuff in the public namespace
>> in a file that will be installed and included by others. I see 3
>> routes out of this:
>>
>> 1. Capability defines should be specified in the commandline. I don't
>> particularly like this.
>> 2. Split the config.h into a public and an internal part, install only
>> the public.
>> 3. Protect the internal defines with __BUILDING_LIBCSOUND or other define.
>>
>> The 3rd option seems the easiest to implement. Would
>> __BUILDING_LIBCSOUND be appropriate for this use? Or should I define a
>> new variable __BUILDING_CSOUND that could act as guard? Or should I go
>> some other route?
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Wouldn't it be easier if the #ifdef __BUILDING_LIBCSOUND were to go
not in config.h but in csoundCore.h?  I'm thinking it would be cleaner
for API developers to not see something if they don't have to.

On Tue, Feb 11, 2014 at 4:46 PM, Felipe Sateler  wrote:
> So, you say config.h should say:
>
> #ifdef __BUILDING_LIBCSOUND
>  #include "csound_private.h"
> #endif
>
>
> And plugin opcodes include csound_private.h manually? Looks like a
> good compromise.
>
>
>
>
> On Tue, Feb 11, 2014 at 5:43 PM, Steven Yi  wrote:
>> Hi Felipe,
>>
>> This seems tricky, as some opcode libraries might depend on a
>> capability. However, I am not certain what those might be, so we would
>> need to do research into what's being used where. We need to have some
>> things be public like MYFLT being double so that API users will
>> automatically have that set. Other things seem to be really for things
>> built within the Csound build system as a whole.  My thought would be
>> to go with route #2 and #3 combined. We could have two headers,
>> config.h.in and config_private.h.in.  The first would be public always
>> and #include'able in csound.h.  config_private.h.in might then be
>> usable when building opcode plugins as well as libcsound.  For opcode
>> plugins, we'd have to add config_private.h to the list of #includes.
>>
>> Does that sound good or have I missed something?
>>
>> Thanks for looking into this!
>> steven
>>
>>
>>
>> On Tue, Feb 11, 2014 at 12:46 PM, Felipe Sateler  wrote:
>>> Hi all,
>>>
>>> Steven prodded me into updating the config-h feature branch for merge,
>>> and in the process I noticed something that it may be desirable to
>>> avoid:
>>>
>>> /home/felipe/src/deb/csound/up/csound6/build/config.h:66:0: warning:
>>> "HAVE_TERMIOS_H" redefined [enabled by default]
>>>  #define HAVE_TERMIOS_H
>>>  ^
>>> In file included from /usr/include/python2.7/pyconfig.h:3:0,
>>>                  from /usr/include/python2.7/Python.h:8,
>>>                  from
>>> /home/felipe/src/deb/csound/up/csound6/build/frontends/CsoundAC/CsoundACPYTHON_wrap.cxx:155:
>>> /usr/include/x86_64-linux-gnu/python2.7/pyconfig.h:823:0: note: this
>>> is the location of the previous definition
>>>  #define HAVE_TERMIOS_H 1
>>>  ^
>>>
>>> So, it is probably a bad idea to define stuff in the public namespace
>>> in a file that will be installed and included by others. I see 3
>>> routes out of this:
>>>
>>> 1. Capability defines should be specified in the commandline. I don't
>>> particularly like this.
>>> 2. Split the config.h into a public and an internal part, install only
>>> the public.
>>> 3. Protect the internal defines with __BUILDING_LIBCSOUND or other define.
>>>
>>> The 3rd option seems the easiest to implement. Would
>>> __BUILDING_LIBCSOUND be appropriate for this use? Or should I define a
>>> new variable __BUILDING_CSOUND that could act as guard? Or should I go
>>> some other route?
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Android apps run on BlackBerry 10
>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>> Get your Android app in front of a whole new audience.  Start now.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That sounds good. Going to do that then.

On Tue, Feb 11, 2014 at 6:50 PM, Steven Yi  wrote:
> Wouldn't it be easier if the #ifdef __BUILDING_LIBCSOUND were to go
> not in config.h but in csoundCore.h?  I'm thinking it would be cleaner
> for API developers to not see something if they don't have to.
>
> On Tue, Feb 11, 2014 at 4:46 PM, Felipe Sateler  wrote:
>> So, you say config.h should say:
>>
>> #ifdef __BUILDING_LIBCSOUND
>>  #include "csound_private.h"
>> #endif
>>
>>
>> And plugin opcodes include csound_private.h manually? Looks like a
>> good compromise.
>>
>>
>>
>>
>> On Tue, Feb 11, 2014 at 5:43 PM, Steven Yi  wrote:
>>> Hi Felipe,
>>>
>>> This seems tricky, as some opcode libraries might depend on a
>>> capability. However, I am not certain what those might be, so we would
>>> need to do research into what's being used where. We need to have some
>>> things be public like MYFLT being double so that API users will
>>> automatically have that set. Other things seem to be really for things
>>> built within the Csound build system as a whole.  My thought would be
>>> to go with route #2 and #3 combined. We could have two headers,
>>> config.h.in and config_private.h.in.  The first would be public always
>>> and #include'able in csound.h.  config_private.h.in might then be
>>> usable when building opcode plugins as well as libcsound.  For opcode
>>> plugins, we'd have to add config_private.h to the list of #includes.
>>>
>>> Does that sound good or have I missed something?
>>>
>>> Thanks for looking into this!
>>> steven
>>>
>>>
>>>
>>> On Tue, Feb 11, 2014 at 12:46 PM, Felipe Sateler  wrote:
>>>> Hi all,
>>>>
>>>> Steven prodded me into updating the config-h feature branch for merge,
>>>> and in the process I noticed something that it may be desirable to
>>>> avoid:
>>>>
>>>> /home/felipe/src/deb/csound/up/csound6/build/config.h:66:0: warning:
>>>> "HAVE_TERMIOS_H" redefined [enabled by default]
>>>>  #define HAVE_TERMIOS_H
>>>>  ^
>>>> In file included from /usr/include/python2.7/pyconfig.h:3:0,
>>>>                  from /usr/include/python2.7/Python.h:8,
>>>>                  from
>>>> /home/felipe/src/deb/csound/up/csound6/build/frontends/CsoundAC/CsoundACPYTHON_wrap.cxx:155:
>>>> /usr/include/x86_64-linux-gnu/python2.7/pyconfig.h:823:0: note: this
>>>> is the location of the previous definition
>>>>  #define HAVE_TERMIOS_H 1
>>>>  ^
>>>>
>>>> So, it is probably a bad idea to define stuff in the public namespace
>>>> in a file that will be installed and included by others. I see 3
>>>> routes out of this:
>>>>
>>>> 1. Capability defines should be specified in the commandline. I don't
>>>> particularly like this.
>>>> 2. Split the config.h into a public and an internal part, install only
>>>> the public.
>>>> 3. Protect the internal defines with __BUILDING_LIBCSOUND or other define.
>>>>
>>>> The 3rd option seems the easiest to implement. Would
>>>> __BUILDING_LIBCSOUND be appropriate for this use? Or should I define a
>>>> new variable __BUILDING_CSOUND that could act as guard? Or should I go
>>>> some other route?
>>>>
>>>> --
>>>>
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Android apps run on BlackBerry 10
>>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>>> Get your Android app in front of a whole new audience.  Start now.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Android apps run on BlackBerry 10
>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>> Get your Android app in front of a whole new audience.  Start now.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I don’t like the idea of plugins having to include more than csdl.h.

Victor
On 11 Feb 2014, at 21:46, Felipe Sateler  wrote:

> So, you say config.h should say:
> 
> #ifdef __BUILDING_LIBCSOUND
> #include "csound_private.h"
> #endif
> 
> 
> And plugin opcodes include csound_private.h manually? Looks like a
> good compromise.
> 
> 
> 
> 
> On Tue, Feb 11, 2014 at 5:43 PM, Steven Yi  wrote:
>> Hi Felipe,
>> 
>> This seems tricky, as some opcode libraries might depend on a
>> capability. However, I am not certain what those might be, so we would
>> need to do research into what's being used where. We need to have some
>> things be public like MYFLT being double so that API users will
>> automatically have that set. Other things seem to be really for things
>> built within the Csound build system as a whole.  My thought would be
>> to go with route #2 and #3 combined. We could have two headers,
>> config.h.in and config_private.h.in.  The first would be public always
>> and #include'able in csound.h.  config_private.h.in might then be
>> usable when building opcode plugins as well as libcsound.  For opcode
>> plugins, we'd have to add config_private.h to the list of #includes.
>> 
>> Does that sound good or have I missed something?
>> 
>> Thanks for looking into this!
>> steven
>> 
>> 
>> 
>> On Tue, Feb 11, 2014 at 12:46 PM, Felipe Sateler  wrote:
>>> Hi all,
>>> 
>>> Steven prodded me into updating the config-h feature branch for merge,
>>> and in the process I noticed something that it may be desirable to
>>> avoid:
>>> 
>>> /home/felipe/src/deb/csound/up/csound6/build/config.h:66:0: warning:
>>> "HAVE_TERMIOS_H" redefined [enabled by default]
>>> #define HAVE_TERMIOS_H
>>> ^
>>> In file included from /usr/include/python2.7/pyconfig.h:3:0,
>>>                 from /usr/include/python2.7/Python.h:8,
>>>                 from
>>> /home/felipe/src/deb/csound/up/csound6/build/frontends/CsoundAC/CsoundACPYTHON_wrap.cxx:155:
>>> /usr/include/x86_64-linux-gnu/python2.7/pyconfig.h:823:0: note: this
>>> is the location of the previous definition
>>> #define HAVE_TERMIOS_H 1
>>> ^
>>> 
>>> So, it is probably a bad idea to define stuff in the public namespace
>>> in a file that will be installed and included by others. I see 3
>>> routes out of this:
>>> 
>>> 1. Capability defines should be specified in the commandline. I don't
>>> particularly like this.
>>> 2. Split the config.h into a public and an internal part, install only
>>> the public.
>>> 3. Protect the internal defines with __BUILDING_LIBCSOUND or other define.
>>> 
>>> The 3rd option seems the easiest to implement. Would
>>> __BUILDING_LIBCSOUND be appropriate for this use? Or should I define a
>>> new variable __BUILDING_CSOUND that could act as guard? Or should I go
>>> some other route?
>>> 
>>> --
>>> 
>>> Saludos,
>>> Felipe Sateler
>>> 
>>> ------------------------------------------------------------------------------
>>> Android apps run on BlackBerry 10
>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>> Get your Android app in front of a whole new audience.  Start now.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
> -- 
> 
> Saludos,
> Felipe Sateler
> 
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Do you mean 3rd party plugins? Or the in-tree plugins?

For the former, csdl.h does #include "config.h". I think that out of
tree plugins should not rely on csounds HAVE_* defines.


On Tue, Feb 11, 2014 at 7:33 PM, Victor Lazzarini
 wrote:
> I don’t like the idea of plugins having to include more than csdl.h.
>
> Victor
> On 11 Feb 2014, at 21:46, Felipe Sateler  wrote:
>
>> So, you say config.h should say:
>>
>> #ifdef __BUILDING_LIBCSOUND
>> #include "csound_private.h"
>> #endif
>>
>>
>> And plugin opcodes include csound_private.h manually? Looks like a
>> good compromise.
>>
>>
>>
>>
>> On Tue, Feb 11, 2014 at 5:43 PM, Steven Yi  wrote:
>>> Hi Felipe,
>>>
>>> This seems tricky, as some opcode libraries might depend on a
>>> capability. However, I am not certain what those might be, so we would
>>> need to do research into what's being used where. We need to have some
>>> things be public like MYFLT being double so that API users will
>>> automatically have that set. Other things seem to be really for things
>>> built within the Csound build system as a whole.  My thought would be
>>> to go with route #2 and #3 combined. We could have two headers,
>>> config.h.in and config_private.h.in.  The first would be public always
>>> and #include'able in csound.h.  config_private.h.in might then be
>>> usable when building opcode plugins as well as libcsound.  For opcode
>>> plugins, we'd have to add config_private.h to the list of #includes.
>>>
>>> Does that sound good or have I missed something?
>>>
>>> Thanks for looking into this!
>>> steven
>>>
>>>
>>>
>>> On Tue, Feb 11, 2014 at 12:46 PM, Felipe Sateler  wrote:
>>>> Hi all,
>>>>
>>>> Steven prodded me into updating the config-h feature branch for merge,
>>>> and in the process I noticed something that it may be desirable to
>>>> avoid:
>>>>
>>>> /home/felipe/src/deb/csound/up/csound6/build/config.h:66:0: warning:
>>>> "HAVE_TERMIOS_H" redefined [enabled by default]
>>>> #define HAVE_TERMIOS_H
>>>> ^
>>>> In file included from /usr/include/python2.7/pyconfig.h:3:0,
>>>>                 from /usr/include/python2.7/Python.h:8,
>>>>                 from
>>>> /home/felipe/src/deb/csound/up/csound6/build/frontends/CsoundAC/CsoundACPYTHON_wrap.cxx:155:
>>>> /usr/include/x86_64-linux-gnu/python2.7/pyconfig.h:823:0: note: this
>>>> is the location of the previous definition
>>>> #define HAVE_TERMIOS_H 1
>>>> ^
>>>>
>>>> So, it is probably a bad idea to define stuff in the public namespace
>>>> in a file that will be installed and included by others. I see 3
>>>> routes out of this:
>>>>
>>>> 1. Capability defines should be specified in the commandline. I don't
>>>> particularly like this.
>>>> 2. Split the config.h into a public and an internal part, install only
>>>> the public.
>>>> 3. Protect the internal defines with __BUILDING_LIBCSOUND or other define.
>>>>
>>>> The 3rd option seems the easiest to implement. Would
>>>> __BUILDING_LIBCSOUND be appropriate for this use? Or should I define a
>>>> new variable __BUILDING_CSOUND that could act as guard? Or should I go
>>>> some other route?
>>>>
>>>> --
>>>>
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Android apps run on BlackBerry 10
>>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>>> Get your Android app in front of a whole new audience.  Start now.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Android apps run on BlackBerry 10
>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>> Get your Android app in front of a whole new audience.  Start now.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-de

I mean any plugins. They should include csdl.h and nothing else from Csound, so I don’t like
the idea of needing also a csound_private.h header.

Victor
On 11 Feb 2014, at 22:47, Felipe Sateler  wrote:

> Do you mean 3rd party plugins? Or the in-tree plugins?
> 
> For the former, csdl.h does #include "config.h". I think that out of
> tree plugins should not rely on csounds HAVE_* defines.
> 
> 
> On Tue, Feb 11, 2014 at 7:33 PM, Victor Lazzarini
>  wrote:
>> I don’t like the idea of plugins having to include more than csdl.h.
>> 
>> Victor
>> On 11 Feb 2014, at 21:46, Felipe Sateler  wrote:
>> 
>>> So, you say config.h should say:
>>> 
>>> #ifdef __BUILDING_LIBCSOUND
>>> #include "csound_private.h"
>>> #endif
>>> 
>>> 
>>> And plugin opcodes include csound_private.h manually? Looks like a
>>> good compromise.
>>> 
>>> 
>>> 
>>> 
>>> On Tue, Feb 11, 2014 at 5:43 PM, Steven Yi  wrote:
>>>> Hi Felipe,
>>>> 
>>>> This seems tricky, as some opcode libraries might depend on a
>>>> capability. However, I am not certain what those might be, so we would
>>>> need to do research into what's being used where. We need to have some
>>>> things be public like MYFLT being double so that API users will
>>>> automatically have that set. Other things seem to be really for things
>>>> built within the Csound build system as a whole.  My thought would be
>>>> to go with route #2 and #3 combined. We could have two headers,
>>>> config.h.in and config_private.h.in.  The first would be public always
>>>> and #include'able in csound.h.  config_private.h.in might then be
>>>> usable when building opcode plugins as well as libcsound.  For opcode
>>>> plugins, we'd have to add config_private.h to the list of #includes.
>>>> 
>>>> Does that sound good or have I missed something?
>>>> 
>>>> Thanks for looking into this!
>>>> steven
>>>> 
>>>> 
>>>> 
>>>> On Tue, Feb 11, 2014 at 12:46 PM, Felipe Sateler  wrote:
>>>>> Hi all,
>>>>> 
>>>>> Steven prodded me into updating the config-h feature branch for merge,
>>>>> and in the process I noticed something that it may be desirable to
>>>>> avoid:
>>>>> 
>>>>> /home/felipe/src/deb/csound/up/csound6/build/config.h:66:0: warning:
>>>>> "HAVE_TERMIOS_H" redefined [enabled by default]
>>>>> #define HAVE_TERMIOS_H
>>>>> ^
>>>>> In file included from /usr/include/python2.7/pyconfig.h:3:0,
>>>>>                from /usr/include/python2.7/Python.h:8,
>>>>>                from
>>>>> /home/felipe/src/deb/csound/up/csound6/build/frontends/CsoundAC/CsoundACPYTHON_wrap.cxx:155:
>>>>> /usr/include/x86_64-linux-gnu/python2.7/pyconfig.h:823:0: note: this
>>>>> is the location of the previous definition
>>>>> #define HAVE_TERMIOS_H 1
>>>>> ^
>>>>> 
>>>>> So, it is probably a bad idea to define stuff in the public namespace
>>>>> in a file that will be installed and included by others. I see 3
>>>>> routes out of this:
>>>>> 
>>>>> 1. Capability defines should be specified in the commandline. I don't
>>>>> particularly like this.
>>>>> 2. Split the config.h into a public and an internal part, install only
>>>>> the public.
>>>>> 3. Protect the internal defines with __BUILDING_LIBCSOUND or other define.
>>>>> 
>>>>> The 3rd option seems the easiest to implement. Would
>>>>> __BUILDING_LIBCSOUND be appropriate for this use? Or should I define a
>>>>> new variable __BUILDING_CSOUND that could act as guard? Or should I go
>>>>> some other route?
>>>>> 
>>>>> --
>>>>> 
>>>>> Saludos,
>>>>> Felipe Sateler
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Android apps run on BlackBerry 10
>>>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>>>> Get your Android app in front of a whole new audience.  Start now.
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Android apps run on BlackBerry 10
>>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>>> Get your Android app in front of a whole new audience.  Start now.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Saludos,
>>> Felipe Sateler
>>> 
>>> ------------------------------------------------------------------------------
>>> Android apps run on BlackBerry 10
>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>> Get your Android app in front of a whole new audience.  Start now.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> 
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
> -- 
> 
> Saludos,
> Felipe Sateler
> 
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net