On 03/05/2011 00:44, Vaughan Johnson wrote:
> On 4/30/2011 9:27 AM, James Crook wrote:
>> Quick answer to Martyn -
>> - I've updated the wiki with instructions for windows.
Thanks for that.
>> - I'm not planning to update the solution file (via the .bat file)
>> with Imagemagick steps.
>> - I'm not averse to it being done, but see discussion below.
>> Slightly longer answer:
>> We/I very much want to encourage new developers.
>> New developers tend to try to build every subproject within a solution.
>> They don't know which ones are vital.
But we can use the 'Configuration Manager' to turn them on and off, as
we want. Having locale, help and some others in there keeps them all
in one place and easy to use for building releases.
>> We want to avoid barriers to them getting started at all. Therefore,
>> the standard solution that developers download and work on should not
>> have additional dependencies on python or on Imagemagick. It shouldn't
>> be fetching files from the wiki. It shouldn't be building an
>> installer. We should also leave out from it legacy projects for ANSI -
>> and experimental plug-ins. We want to get them off the ground quickly,
>> and every one of these details is something that stands in their way.
> I agree.
I agree to reducing barriers, but at the expense of productivity for
>> Do we need a reduced version of Audacity.sln with minimal dependencies
>> on other installed software? Or is it better to have a full version and
>> give clearer instructions in wiki of how to get started - of what not to
>> build? I don't know.
No. That would mean maintaining a sln that none of us regularly use.
If we changed something that broke the 'minimal' one the first
person to notice would be that new dev we are trying to help! That
would defeat the object.
I say the Configuration Manager is the way to go here. Presumably new
devs would want to build Unicode Debug? Let's turn off the building
of help in both Debug versions by default, and anything else that we
don't actually use in all 4 versions. Then think about dropping the
ANSI versions, leaving just 2.
>> Longest answer:
>> What should go in the solution files? Should we be using Solution files
>> at all for the actual builds?
>> Linux is great since we can easily have different build targets. We can
>> put everything in the one make file and users just choose different
>> targets depending on whether they want to:
>> Build optional libraries
>> Build plug-ins
>> Copy Nyquist files from one place to another
>> Do the funky steps with portmixer source
>> Fetch the manual files (needs python)
>> Shrink the manual images (needs imagemagick)
>> On wiki (and in the makefile) we can easily document the different make
>> Windows is a mess. We have four configurations, Debug, Release, Unicode
>> Debug, Unicode Release. I've recently been wondering whether to include
>> the mod-null, mod-nyq-bench, mod-script-pipe and mod-track-panel in the
>> standard solution. I decided not, because at the moment they are only
>> for the adventurous. They exist as separate project files. It's easy
>> enough to add a project file into a solution later.
>> In Windows what gets built is very closely tied to the 'solution
>> explorer' tree structure.
> Isn't that actually based on the Project> Dependencies?
>> That's simple but inflexible. We must use
>> that tree structure if we're using windows since it is integral to
>> navigating in the IDE. We don't have to use it for the building
>> though. However, if we use an external linux-compatible make file, it
>> has to be kept in sync with the tree in the sln/vcproj - or confusion
>> ensues. That need to sync works against us adopting the same solution
>> for windows and linux.
>> I think we should be planning to move to an external makefile using
>> MSBuild. The tools menu allows us to add external tools such as a build
>> script as a menu items in the tools menu. That way for normal use we
>> could use the integrated build tools to do regular every-day development
>> and the tools menu item to do the complete build process with installer
>> and help for release builds.
>> I think the ideal solution is a script that builds the solution files,
>> project files and make files from a higher level description. SCONS and
>> CMAKE fit the bill and are worth investigating further. Both can
>> produce Windows solutions. Getting a SCONS or CMAKE solution set up is
>> probably not our top priority, so the question remains what to do in the
> I agree it's not a priority. Good ideas, though.
Indeed, as long as devs don't have to pay for any software. I have
only just read a bit about MSBuild and we'd need several people who
could work it before we switched.
>> In the interim I suspect the best way is to treat building the manual as
>> something that happens entirely outside the .sln file. We possibly need
>> an overarching python script that is a scripted version of the build
>> steps on the wiki, and that includes building the manual.
>> In the interim we keep audacity.sln to a minimum, it just builds
>> audacity. We add help to the wiki about including .vcproj files for
>> additional plug-ins and other experimental code.
OK, but let's not take out what's there for 'help'.
> - Vaughan
>> On 30/04/2011 00:09, Martyn Shaw wrote:
>>> Confirming that that (almost) works here as well, with minimal loss of
>>> quality and a similar decrease in file size.
>>> I had to install imagemagickhttp://www.imagemagick.org and needed
>>> '%a' rather than '%%a' here.
>>> Care to update
>>> http://wiki.audacityteam.org/wiki/Release_Process/Win#Manual and,
>>> better still, the sln file?
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> audacity-devel mailing list