|
»
»
»
« Return to Thread: working towards a modular plugin based audacity
Re: working towards a modular plugin based audacity
by James Crook
::
Rate this Message:
Richard Ash wrote:
> On Sat, 2008-04-26 at 18:24 +0100, James Crook wrote:
>
>> Richard Ash wrote:
>>
>>> On Fri, 2008-04-25 at 23:16 +0100, James Crook wrote:
>>>
>>> Should I be building with
>>> #define EXPERIMENTAL_MODULES 1
>>> #define BUILDING_AUDACITY 1
>>> #define WXUSINGDLL 1
>>>
>>>
>> That's correct. These defines should ensure that 'LoadModules' is
>> called early on. If the loaded modules define the searched for exports,
>> then we will get one or more of scriptFn and pPanelHijack defined.
>> scriptFn non NULL will lead to a new thread being started for script.
>> pPanelHijack will lead to the GUI being 'hijacked'.
>>
>
> OK, then some work needed. WXUSINGDLL is OK, and so LoadModules gets
> included, but trying to turn on either of the other two results in
> compile errors in Audacity.h. I think the way we define AUDACITY_DLL_API
> is implicated here.
>
> Am I right in thinking that this is supposed to be defined to one thing
> when BUILDING_AUDACITY is defined during the build of audacity, and
> another when (some other macro) is defined during building the module?
>Yes. AUDACITY_DLL_API is defined:
1) to export the classes/functions/variables if BUILDING_AUDACITY defined,
2) to import if BUILDING_AUDACITY is not defined AND _DLL is, which is
the case when building some DLL that will work with Audacity and that
needs to use some of Audacity headers to get to Audacity code /
functionality,
3) to be empty/blank if neither BUILDING_AUDACITY nor _DLL is defined -
which brings us back to the 'old' case (monolithic builds).
The definition _declpec(dllexport) is windows specific and would need to
change to whatever the gcc equivalent is. This link gives clues to the
possible gcc translation.
http://gcc.gnu.org/wiki/Visibility
> As a spin off from this presumably the modules need to be able to find
> Audacity.h during compilation? Any other headers they are going to need
> to be able to find?
>
Yes they should, but for mod-script-pipe I cheated so that it doesn't.
You'll see that it typedefs a declspec(dllimport) of tpExecScriptServerFunc.
There is only one function in Audacity which it needs to call, and that
is the function that takes a wxString * in and out variable. It calls
it to exec the corresponding Audacity command.
mod-script-pipe is built as a dll and defines BUILDING_SCRIPT_PIPE and
WXUSINGDLL.
An earlier version of it used the ShuttleGui class, and would have
required the shuttlegui.h include. However that is not in the current
version, which keeps things a little simpler for now. The include is
still there, but not needed.
For the hijacker plug in a great many audacity header files are
included, but I think hijacking is for another day, i.e. after GSoC.
> I don't intend to do much on this before 1.3.5, although I would like to
> get away from defining AUDACITY_DLL_API if we can (a bit of logic in
> Audacity.h might well solve the problem) because of the problems on with
> the Sun compiler and because it doesn't fit with the rest of the build
> system (where defines go in configunix.h) terribly well.
>
I'm unclear about your intention here. AUDACITY_DLL_API is not defined
on the command line in windows builds. It is only defined by
Audacity.h. Are you planning to change that?
--James.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel
> On Sat, 2008-04-26 at 18:24 +0100, James Crook wrote:
>
>> Richard Ash wrote:
>>
>>> On Fri, 2008-04-25 at 23:16 +0100, James Crook wrote:
>>>
>>> Should I be building with
>>> #define EXPERIMENTAL_MODULES 1
>>> #define BUILDING_AUDACITY 1
>>> #define WXUSINGDLL 1
>>>
>>>
>> That's correct. These defines should ensure that 'LoadModules' is
>> called early on. If the loaded modules define the searched for exports,
>> then we will get one or more of scriptFn and pPanelHijack defined.
>> scriptFn non NULL will lead to a new thread being started for script.
>> pPanelHijack will lead to the GUI being 'hijacked'.
>>
>
> OK, then some work needed. WXUSINGDLL is OK, and so LoadModules gets
> included, but trying to turn on either of the other two results in
> compile errors in Audacity.h. I think the way we define AUDACITY_DLL_API
> is implicated here.
>
> Am I right in thinking that this is supposed to be defined to one thing
> when BUILDING_AUDACITY is defined during the build of audacity, and
> another when (some other macro) is defined during building the module?
>
1) to export the classes/functions/variables if BUILDING_AUDACITY defined,
2) to import if BUILDING_AUDACITY is not defined AND _DLL is, which is
the case when building some DLL that will work with Audacity and that
needs to use some of Audacity headers to get to Audacity code /
functionality,
3) to be empty/blank if neither BUILDING_AUDACITY nor _DLL is defined -
which brings us back to the 'old' case (monolithic builds).
The definition _declpec(dllexport) is windows specific and would need to
change to whatever the gcc equivalent is. This link gives clues to the
possible gcc translation.
http://gcc.gnu.org/wiki/Visibility
> As a spin off from this presumably the modules need to be able to find
> Audacity.h during compilation? Any other headers they are going to need
> to be able to find?
>
Yes they should, but for mod-script-pipe I cheated so that it doesn't.
You'll see that it typedefs a declspec(dllimport) of tpExecScriptServerFunc.
There is only one function in Audacity which it needs to call, and that
is the function that takes a wxString * in and out variable. It calls
it to exec the corresponding Audacity command.
mod-script-pipe is built as a dll and defines BUILDING_SCRIPT_PIPE and
WXUSINGDLL.
An earlier version of it used the ShuttleGui class, and would have
required the shuttlegui.h include. However that is not in the current
version, which keeps things a little simpler for now. The include is
still there, but not needed.
For the hijacker plug in a great many audacity header files are
included, but I think hijacking is for another day, i.e. after GSoC.
> I don't intend to do much on this before 1.3.5, although I would like to
> get away from defining AUDACITY_DLL_API if we can (a bit of logic in
> Audacity.h might well solve the problem) because of the problems on with
> the Sun compiler and because it doesn't fit with the rest of the build
> system (where defines go in configunix.h) terribly well.
>
I'm unclear about your intention here. AUDACITY_DLL_API is not defined
on the command line in windows builds. It is only defined by
Audacity.h. Are you planning to change that?
--James.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel
« Return to Thread: working towards a modular plugin based audacity
| Free Forum Powered by Nabble | Forum Help |