Re: [Audacity-devel] What should go in solution files?

[James C. <cr...@in...>]

Quick answer to Martyn -
  - I've updated the wiki with instructions for windows.
  - 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.

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.

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.

---

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


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

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.

--James.








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