Re: [Audacity-devel] Windows build, CVS changes

[Joshua H. <jha...@up...>]

* Dominic Mazzoni (do...@mi...) wrote:
> Hi everyone,
> 
> I got Audacity to build on Windows and checked everything in.
> I had to make minor changes to source files, and I almost
> completely redid the project file to handle our new layout
> for sublibraries.

Did you check in binaries for all the library builds? This is when the
advantages of lib-src will kick in -- once you check in binaries of the
libraries, no one doing development on Windows should need to check out
audacity-all, because they won't need lib-src.

> I'm planning to submit a request to Sourceforge that they
> take the audacity repository and they rename it audacity-1
> (i.e. Audacity 1.0, since we'll still have to use this
> repository to work on the 0.9 -> 1.0 branch).

Will audacity-all still check out audacity-1 and lib-src beneath it?

> Once that's done, I'll create a new repository called
> "audacity-src" with this layout:
> 
> help/
> mac/
> src/
> src/effects
> src/effects/VST
> src/prefs
> src/widgets
> src/xpm
> win/

Could you be a bit more detailed? Where do library include files go?
Where do png's go? Are you planning to check in allegro/ or snd/? 

Also, in the new tree, please put BladeMP3EncDLL.h whereever the other
libraries' include files go. I think it makes more sense. Also, don't
copy lame.h over at all (unless you're using it on the Mac). I think mp3
exporting needs to be rethought on Linux. Judging from the number of
complaints we've gotten that people can't change the bit rate, I think a
different solution needs to be found. I think these are our two options:

1. Require the user to copy the lame.h from whatever version of the .so
   they've built, so we're sure it's the right version.

2. Require the latest version of lame, which is written to actually be
   binary compatible across versions (it uses functions to set parameters
   instead of having the client set fields in structs).

> There will no longer be a repository called audacity - instead
> audacity will be an alias that downloads audacity-src as
> "audacity" and downloads lib-src inside it (i.e. just what
> audacity-all does now).  That way if we ever need to start
> over again, we don't need to ask Sourceforge to rename anymore,
> we just have "audacity" alias to something else.

This highlights another advantage of lib-src -- since it's separate from
our source tree, even though Audacity's tree is undergoing
reorganization, both trees can still point to the same lib-src since it's
not affected.

Joshua

-- 
Joshua Haberman  <jo...@ha...>