Re: [Audacity-devel] Windows build, CVS changes
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Dominic M. <do...@mi...> - 2001-11-12 05:46:52
|
> 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. No, I didn't yet, and I'm not 100% sure that I want to anymore. If you open the Audacity workspace, you can compile all of the libraries with one click - and this is more likely to be up-to-date, especially since many of our libraries (portaudio and libsndfile) are under revision right now, adding features we're looking forward to. If we do want to store Windows library binaries, maybe we should put them in a separate repository. But I like the way it's set up now - it's really very easy to compile the whole thing, and I did my best to leave the libraries alone (i.e. I let them put the built library wherever they normally do). > Will audacity-all still check out audacity-1 and lib-src beneath it? Sure, why not? >> 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/? snd/ and allegro/ will go in lib-src, where they belong, for as long as we need them. We'll be getting rid of snd/ soon, but I don't see any reason not to keep it in lib-src. In the future we might want to compare it to libsndfile from time to time as a sanity check. For the time being, all of our inline images are either xpm files (which are by far the easiest way to include cross-platform images) or they're part of the help file. It would be nice to check in all of the originals of these images, plus all of our other artwork. (I have the original multi-layer Gimp files for the buttons, for example.) In my opinion, these should go in an entirely separate repository, since they're not really tied to any particular release. How about a new repository called "artwork" or "images"? As for library include files, I think they should go in src/include/. If they were just in include/, people would think that they're include files for Audacity itself - i.e. if Audacity could be scripted from another program. >> 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. Yes! - Dominic |