[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] Windows build
From: |
Bernhard Schelling |
Subject: |
Re: [fluid-dev] Windows build |
Date: |
Mon, 17 Sep 2007 15:02:30 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 |
Hi Josh, Hi mailing list
After making a few changes to the existing VC++ 6 project and some
source files I was able to build FluidSynth on Visual Studio 2003.
Since I don't have VC++ 6, I was wondering if I should just remove the
older VC 6 project files and add the newer VS 2003 files.
Is anyone currently using the VC 6 project files for doing Windows
builds?
We are using a modified/hacked version of FluidSynth for our current project
(expect a rather large mostly useless chunk of patches sooner or later on this
list).
I mostly use VC6 on my machines for my builds. Other members of our project use VC8 (VS2005) and for gcc/linux regular makefiles. The VC8 build are being done
by converting the changed DSP VC6 projects which I use.
There are a few changes which were required to make these builds possible.
In the DSP I added the files for aufile, dspfloat and removed strtok which
doesn't exist anymore but is still referenced in the DSP.
For the source itself a few changes were necessary for getting it built under
the standards incompatible VC6 compiler.
- changed some of the "#include "config.h"" to "#include "fluidsynth_priv.h"" -
obviously required on systems without HAVE_CONFIG_H
- removed all inline keywords (used for 4 static inline functions) - not
supported for non C++ C code in VC6
Other than that it works very well.
Seeing that VC2003 and VC2005 load/convert and build the VC6 DSP projects
without any problems, I'd suggest keeping the VC6 ones.
But there is a tool available to backconvert the projects at http://www.codeproject.com/tools/prjconverter.asp - so I guess that could be an option, too, for
the few people who still use VC6 (which includes me because I like the small size and speed of the whole IDE and compile environment - not so much the compiler
itself).
Greetings from Switzerland,
Bernhard
PS: If this mail doesn't get correctly attached to it's parent posting in the list thread, it's because I just subscribed and couldn't correctly reply to the
message.