working towards a modular plugin based audacity

[Federico Grau-2]

Hello Audacity developers,

This email is to start a discussion on how best to transition to a modular
plugin based Audacity.  This idea has been tossed around in the past on the
mailing list and on the wiki (
http://www.audacityteam.org/wiki/index.php?title=Roadmap
http://www.audacityteam.org/wiki/index.php?title=Audacity-Extra ).  

With the shuffling that will be going on soon for GSOC, now (the next several
weeks before GSOC coding actually starts) is an opportune time to try to make
this transition.


Steps towards this goal include:
 - standardize to using wx 2.8 which I understand to have better support for a
   modular build
 - Audacity Windows build should switch from a static build to a DLL build
 - there should be a basic template/test module/plugin to confirm the new
   modular design works and to provide an example for new modules to be built
   against


On my end, I'll be checking out:
 - get wx 2.8 libs working in my Linux environment (debian stable)
 - get a windows build env setup
 - review the work Dominic and James have done already on src/LoadModules*


What do others think?

regards,
donfede

--
Federico Grau
Free Software Developer and Sysadmin
Radio Free Asia
2025 M Street, NW
Suite 300
Washington, DC  20036
202-587-2046  Telephone
202-721-7468  Facsimile
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and may
contain information that is privileged and confidential.  Any unauthorized
dissemination, distribution, or copying is strictly prohibited.  If you
receive this transmission in error, please contact network@....

-------------------------------------------------------------------------
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

[James Crook]

Federico,

I'd be strongly in favour of a shift to wx2.8 and to building with
wxWidgets as DLL at the same time.  If we don't do it now, we'll never
do it :-)
We could then drop the custom-sln for wxWidgets, which would be a very
welcome step.  We'd use the standard wxWidgets supplied one and our own
config (to get accessibility).

Installers would need modifying to install the wxWidgets DLLs.  I'm not
sure much else would need to change?

--James.


Federico Grau wrote:

> Hello Audacity developers,
>
> This email is to start a discussion on how best to transition to a modular
> plugin based Audacity.  This idea has been tossed around in the past on the
> mailing list and on the wiki (
> http://www.audacityteam.org/wiki/index.php?title=Roadmap
> http://www.audacityteam.org/wiki/index.php?title=Audacity-Extra ).  
>
> With the shuffling that will be going on soon for GSOC, now (the next several
> weeks before GSOC coding actually starts) is an opportune time to try to make
> this transition.
>
>
> Steps towards this goal include:
>  - standardize to using wx 2.8 which I understand to have better support for a
>    modular build
>  - Audacity Windows build should switch from a static build to a DLL build
>  - there should be a basic template/test module/plugin to confirm the new
>    modular design works and to provide an example for new modules to be built
>    against
>
>
> On my end, I'll be checking out:
>  - get wx 2.8 libs working in my Linux environment (debian stable)
>  - get a windows build env setup
>  - review the work Dominic and James have done already on src/LoadModules*
>
>
> What do others think?
>
> regards,
> donfede
>
>  

-------------------------------------------------------------------------
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

[Vaughan]

Seems good to me. Can we complete and release 1.3.5 first, then switch
to modular build and at least freeze it as an internal release before
the GSoC students start?

- V

James Crook wrote:

> Federico,
>
> I'd be strongly in favour of a shift to wx2.8 and to building with
> wxWidgets as DLL at the same time.  If we don't do it now, we'll never
> do it :-)
> We could then drop the custom-sln for wxWidgets, which would be a very
> welcome step.  We'd use the standard wxWidgets supplied one and our own
> config (to get accessibility).
>
> Installers would need modifying to install the wxWidgets DLLs.  I'm not
> sure much else would need to change?
>
> --James.
>
>
> Federico Grau wrote:
>  
>> Hello Audacity developers,
>>
>> This email is to start a discussion on how best to transition to a modular
>> plugin based Audacity.  This idea has been tossed around in the past on the
>> mailing list and on the wiki (
>> http://www.audacityteam.org/wiki/index.php?title=Roadmap
>> http://www.audacityteam.org/wiki/index.php?title=Audacity-Extra ).  
>>
>> With the shuffling that will be going on soon for GSOC, now (the next several
>> weeks before GSOC coding actually starts) is an opportune time to try to make
>> this transition.
>>
>>
>> Steps towards this goal include:
>>  - standardize to using wx 2.8 which I understand to have better support for a
>>    modular build
>>  - Audacity Windows build should switch from a static build to a DLL build
>>  - there should be a basic template/test module/plugin to confirm the new
>>    modular design works and to provide an example for new modules to be built
>>    against
>>
>>
>> On my end, I'll be checking out:
>>  - get wx 2.8 libs working in my Linux environment (debian stable)
>>  - get a windows build env setup
>>  - review the work Dominic and James have done already on src/LoadModules*
>>
>>
>> What do others think?
>>
>> regards,
>> donfede
>>
>>  
>>    
>
>
> -------------------------------------------------------------------------
> 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
>
>  

-------------------------------------------------------------------------
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

[Vaughan]

That "at least" is vs releasing 1.3.6 as the first modular-built release
-- which I think is quite possible by end of May.

Vaughan Johnson wrote:

> Seems good to me. Can we complete and release 1.3.5 first, then switch
> to modular build and at least freeze it as an internal release before
> the GSoC students start?
>
> - V
>
> James Crook wrote:
>> Federico,
>>
>> I'd be strongly in favour of a shift to wx2.8 and to building with
>> wxWidgets as DLL at the same time.  If we don't do it now, we'll
>> never do it :-)
>> We could then drop the custom-sln for wxWidgets, which would be a
>> very welcome step.  We'd use the standard wxWidgets supplied one and
>> our own config (to get accessibility).
>>
>> Installers would need modifying to install the wxWidgets DLLs.  I'm
>> not sure much else would need to change?
>>
>> --James.
>>
>>
>> Federico Grau wrote:
>>  
>>> Hello Audacity developers,
>>>
>>> This email is to start a discussion on how best to transition to a
>>> modular
>>> plugin based Audacity.  This idea has been tossed around in the past
>>> on the
>>> mailing list and on the wiki (
>>> http://www.audacityteam.org/wiki/index.php?title=Roadmap
>>> http://www.audacityteam.org/wiki/index.php?title=Audacity-Extra ).
>>> With the shuffling that will be going on soon for GSOC, now (the
>>> next several
>>> weeks before GSOC coding actually starts) is an opportune time to
>>> try to make
>>> this transition.
>>>
>>>
>>> Steps towards this goal include:
>>>  - standardize to using wx 2.8 which I understand to have better
>>> support for a
>>>    modular build
>>>  - Audacity Windows build should switch from a static build to a DLL
>>> build
>>>  - there should be a basic template/test module/plugin to confirm
>>> the new
>>>    modular design works and to provide an example for new modules to
>>> be built
>>>    against
>>>
>>>
>>> On my end, I'll be checking out:
>>>  - get wx 2.8 libs working in my Linux environment (debian stable)
>>>  - get a windows build env setup
>>>  - review the work Dominic and James have done already on
>>> src/LoadModules*
>>>
>>> What do others think?
>>>
>>> regards,
>>> donfede
>>>
>>>      
>>
>>
>> -------------------------------------------------------------------------
>>
>> 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
>>
>>  
>

-------------------------------------------------------------------------
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

[Richard Ash (audacity-help)]

On Fri, 2008-04-25 at 13:49 -0700, Vaughan Johnson wrote:
> Seems good to me. Can we complete and release 1.3.5 first, then switch
> to modular build and at least freeze it as an internal release before
> the GSoC students start?

Can someone clarify what a "modular build" means if you aren't on
Windows? Linking to wxGTK dynamically is trivial and already implemented
in the auto* build process. As far as I know the other plug-in stuff
isn't portable at all yet (unless it's moved on recently).

Richard


-------------------------------------------------------------------------
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

[James Crook]

Richard Ash wrote:

> On Fri, 2008-04-25 at 13:49 -0700, Vaughan Johnson wrote:
>  
>> Seems good to me. Can we complete and release 1.3.5 first, then switch
>> to modular build and at least freeze it as an internal release before
>> the GSoC students start?
>>    
>
> Can someone clarify what a "modular build" means if you aren't on
> Windows? Linking to wxGTK dynamically is trivial and already implemented
> in the auto* build process. As far as I know the other plug-in stuff
> isn't portable at all yet (unless it's moved on recently).
>
> Richard

Richard - It sounds then like modular Linux build is already there, so
it's just a matter of 'proving' is through a 'Null' plug-in.

Doing a 'last monolithic' (1.3.5) and a 'first modular' (1.3.6) betas
could be good.  I thought there was still too much to do to do a stable
release though....

The existing script plug in uses named pipes and requires Windows header
files that aren't part of Linux, so is windows only.  Perhaps I should
have used wxTCP to be cross platform, but I wanted to avoid having the
WindowsXP firewall complain about starting up a TCP/IP server.

Federico's suggestion of an 'empty' plug in could be done by cutting out
all the windows pipe stuff.  It could for example pop up a dialog to
show that loading the module and calling wxWidgets functions was
working.  That's all that's needed at this stage.  Then it could work on
both Windows and Linux.

--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

[Martyn Shaw-2]

Hi

Would moving to 'modular' audacity mean that using external dlls would
be easier?  I've mentioned it here before but I'll do so again, fftw
is a rather useful dll that I can't figure out how to use in the
static build.  Would it be easier in a modular build?

Martyn

James Crook wrote:

> Federico,
>
> I'd be strongly in favour of a shift to wx2.8 and to building with
> wxWidgets as DLL at the same time.  If we don't do it now, we'll never
> do it :-)
> We could then drop the custom-sln for wxWidgets, which would be a very
> welcome step.  We'd use the standard wxWidgets supplied one and our own
> config (to get accessibility).
>
> Installers would need modifying to install the wxWidgets DLLs.  I'm not
> sure much else would need to change?
>
> --James.
>
>
> Federico Grau wrote:
>> Hello Audacity developers,
>>
>> This email is to start a discussion on how best to transition to a modular
>> plugin based Audacity.  This idea has been tossed around in the past on the
>> mailing list and on the wiki (
>> http://www.audacityteam.org/wiki/index.php?title=Roadmap
>> http://www.audacityteam.org/wiki/index.php?title=Audacity-Extra ).  
>>
>> With the shuffling that will be going on soon for GSOC, now (the next several
>> weeks before GSOC coding actually starts) is an opportune time to try to make
>> this transition.
>>
>>
>> Steps towards this goal include:
>>  - standardize to using wx 2.8 which I understand to have better support for a
>>    modular build
>>  - Audacity Windows build should switch from a static build to a DLL build
>>  - there should be a basic template/test module/plugin to confirm the new
>>    modular design works and to provide an example for new modules to be built
>>    against
>>
>>
>> On my end, I'll be checking out:
>>  - get wx 2.8 libs working in my Linux environment (debian stable)
>>  - get a windows build env setup
>>  - review the work Dominic and James have done already on src/LoadModules*
>>
>>
>> What do others think?
>>
>> regards,
>> donfede
>>
>>  
>
>
> -------------------------------------------------------------------------
> 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
>

-------------------------------------------------------------------------
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

[Richard Ash (audacity-help)]

On Fri, 2008-04-25 at 23:16 +0100, James Crook wrote:
> Richard Ash wrote:
> Richard - It sounds then like modular Linux build is already there, so
> it's just a matter of 'proving' is through a 'Null' plug-in.

Should I be building with
#define EXPERIMENTAL_MODULES 1
#define BUILDING_AUDACITY 1
#define WXUSINGDLL 1

to enable this, or are they something else? I think some of the
pre-processor magic is currently VC++ - specific, but there are GCC
equivalents we can use.

Richard


-------------------------------------------------------------------------
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

[James Crook]

Richard Ash wrote:

> On Fri, 2008-04-25 at 23:16 +0100, James Crook wrote:
>  
>> Richard Ash wrote:
>> Richard - It sounds then like modular Linux build is already there, so
>> it's just a matter of 'proving' is through a 'Null' plug-in.
>>    
>
> 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'.

--James.

> to enable this, or are they something else? I think some of the
> pre-processor magic is currently VC++ - specific, but there are GCC
> equivalents we can use.

> Richard
>
> -------------------------------------------------------------------------
> 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
>
>
>  

-------------------------------------------------------------------------
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

[Richard Ash (audacity-help)]

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?
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?

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.

Richard


-------------------------------------------------------------------------
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

[James Crook]

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

[Richard Ash (audacity-help)]

On Sun, 2008-04-27 at 23:21 +0100, James Crook wrote:
> 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

Yes, I think I've seen that before.

> > 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.

Fair enough. In the larger picture, I think we need to install
Audacity.h when installing audacity, so that external modules (should
some appear) can locate it and use it when they are built. Obviously, we
will need to work out and document what the right generic defines for
this use are.

> 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.
That makes sense - one step at a time.

> > 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?
On *nix the configure script adds -DAUDACITY_DLL_API='' to the CPPFLAGS
so it's added to every C++ compiler command line in the build. The
effect is to add the define to every compile, effectively before the
start of the source code. This has some issues, and from what you are
saying is not necessary.

Richard Ash


-------------------------------------------------------------------------
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

[Richard Ash (audacity-help)]

On Sun, 2008-04-27 at 23:21 +0100, James Crook wrote:

> 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

Right, I've written the relevant pre-processor and configure script code
to make this happen. I've hit a problem at in SampleFormat.h:31:

AUDACITY_DLL_API samplePtr NewSamples(int count, sampleFormat format);
AUDACITY_DLL_API void DeleteSamples(samplePtr p);

With GCC, the visibility stuff has to come after the type definition,
i.e. the current code is a compile error, to make it work I have to
change to:

samplePtr AUDACITY_DLL_API NewSamples(int count, sampleFormat format);
void AUDACITY_DLL_API DeleteSamples(samplePtr p);

What I don't know is if it will compile (or work) on windows if I make
this change. Can anyone try this out?

Assuming that it does, there are a load of similar changes in
LoadModules.cpp to make. Having done these, I have got it to compile,
although link fails because NonGuiThread::StartChild() is missing. I
suspect this means we need to build and link the stuff in
lib-src/lib-widget-extra/. Before we go down that path though, a
question: Do we envisage building audacity without the basic module
loading code in future? If we don't, what are the pros and cons of
moving the stuff from lib-widget-extra into the audacity source tree? Is
it actually helpful to have it is a library that only we use?

Richard


-------------------------------------------------------------------------
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

[gale-3]

| From Richard Ash <richard@...>
| Sat, 10 May 2008 22:00:37 +0100
| Subject: [Audacity-devel] working towards a modular plugin based audacity
|  > On Sun, 2008-04-27 at 23:21 +0100, James Crook wrote:

> > 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
>
>
> Right, I've written the relevant pre-processor and configure script code
> to make this happen. I've hit a problem at in SampleFormat.h:31:  
>
> AUDACITY_DLL_API samplePtr NewSamples(int count, sampleFormat format);
> AUDACITY_DLL_API void DeleteSamples(samplePtr p);
>
> With GCC, the visibility stuff has to come after the type definition,
> i.e. the current code is a compile error, to make it work I have to
> change to:
>
> samplePtr AUDACITY_DLL_API NewSamples(int count, sampleFormat format);
> void AUDACITY_DLL_API DeleteSamples(samplePtr p);
>
> What I don't know is if it will compile (or work) on windows if I make
> this change. Can anyone try this out?

If it helps, I substituted:

samplePtr AUDACITY_DLL_API NewSamples(int count, sampleFormat format);
void AUDACITY_DLL_API DeleteSamples(samplePtr p);

for

AUDACITY_DLL_API samplePtr NewSamples(int count, sampleFormat format);
AUDACITY_DLL_API void DeleteSamples(samplePtr p);

on lines 41 - 2 (not 31) of Sample Format.h and it compiles on Windows
XP using Visual Studio 2005, wxWidgets 2.6.4 Unicode Release (and
Audacity launches OK). Can't help if you wanted a .dll build with 2.8.7
as I have much the same problem as Martyn at the moment:=)


Gale  






-------------------------------------------------------------------------
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

[Richard Ash (audacity-help)]

On Sun, 2008-05-11 at 05:49 +0100, Gale Andrews wrote:

> | From Richard Ash <richard@...>
> | Sat, 10 May 2008 22:00:37 +0100
> | Subject: [Audacity-devel] working towards a modular plugin based audacity
> > Right, I've written the relevant pre-processor and configure script code
> > to make this happen. I've hit a problem at in SampleFormat.h:31:  
> >
> > AUDACITY_DLL_API samplePtr NewSamples(int count, sampleFormat format);
> > AUDACITY_DLL_API void DeleteSamples(samplePtr p);