[Clam-devel] Re: [CLAM] building on windows.

[David García Garzón]

On Saturday 29 September 2007 04:34:14 Ali-Akber Saifee wrote:
> Hi David,
>
> Thanks for the info.  Atleast now I don't feel like a complete idiot for
> not being able to compile CLAM :D The reason why compilation errors may be
> appearing on my build environment is because of the updated compiler from
> Microsoft which seems to be getting more and more pedantic. For example the
> following code will no longer compile under VS2005+..
> for(int i(0); i < i ; ++i);
> for(i = 0 ; i < i ; ++i);
>
> it has to be.
> int i(0);
> for (i = 0..
> for (i = 0..

First of all, which files have this problem?

In fact, the CLAM coding standard is defining vars as local as possible, so:
for (int i=0...
for (int i=0...
Which is C++ standard compliant. The problem previous versions of VC did 
compile such code due to a bad standard implementation of the 'for' loop 
scoping, so we defined the following hack:
#ifdef MSVC_VER_
#define for if (true) for
#endif

We removed such hack as we dropped VC support. I don't know whether VS2005 
still has this flaw. You could move the hack back to 
CLAM/src/Defines/OSDefines.hxx

And add again the VC preinclude option including such a header for every file.

> Theres various other new caveats that have popped up and require loads of
> rework on old code that just worked before.
>
> Anyways,
> I'm more than happy to use MingW (especially since it will ensure a mental
> check for platform independent code). I did notice though, that there
> aren't too many instructions on how to set up a build env with MingW. Any
> pointers?

In fact we are crosscompiling from Linux, we have not even tested the build in 
a regular windows installation. The crosscompiled process is available here:
http://clam.iua.upf.edu/wikis/clam/index.php/Devel/Windows_MinGW_cross_compile

There is also an (outdated) development package with all the binaries compiled 
that you could use to compile your own program:
http://clam.iua.upf.edu/download/win/mingw32-spike/clam-devel-mingw-1.1.1%7Esvn10446.zip

But no guarantees they work.

> I tried the latest svn snapshot build of NetworkEditor - and the
> processings work! This obviously points to the fact that the MingW
> compilation is more predictable - and I guess, should be the path to take.

Yep.

> Looking forward to hearing from you.

We are too.

> p.s. one of the compilation errors I hit with MSVC is in AudioMixer.cxx as
> below.
>
> f:\clam\trunk\clam\scons\libs\processing\src\audiomixer.cxx(100) : error
> C2057: expected constant expression


This is an optimization we did after the VC drop. Formerly we used a 
dynamically allocated array of pointers. Try by defining numInPorts as const. 
If it doesnt work 


> f:\clam\trunk\clam\scons\libs\processing\src\audiomixer.cxx(100) : error
> C2466: cannot allocate an array of constant size 0
> f:\clam\trunk\clam\scons\libs\processing\src\audiomixer.cxx(100) : error
> C2133: 'inputs' : unknown size
> f:\clam\trunk\clam\scons\libs\processing\src\audiomixer.cxx(101) : error
> C2057: expected constant expression
> f:\clam\trunk\clam\scons\libs\processing\src\audiomixer.cxx(101) : error
> C2466: cannot allocate an array of constant size 0
> f:\clam\trunk\clam\scons\libs\processing\src\audiomixer.cxx(101) : error
> C2133:'controls' : unknown size
>
> On 9/28/07, David García Garzón <dgarcia at iua.upf.edu> wrote:
> > After having a lot of problems trying to have a reproducible VisualC
> > environment, we dropped VC support in CLAM version 1.1, in favor of
> > mingw. In
> > fact, one of the reasons was that we were having problem with the static
> > objects we use to intitialize processings factory. They should be working
> > perfectly with wine. To my suprise you seem to have the same problem (not
> > being able to create some processing types) with precompiled 1.1.0
> > version of
> > the NetEditor available on the web which was already compiled with mingw.
> >
> > We are currently moving to a new office. So we can not test the binaries
> > to
> > check what's happening. Just to be sure, try one of the latest
> > svnsnapshots
> > at:
> > http://clam.iua.upf.edu/download/win/svnsnapshots/
> >
> > I just tested the latest snapshot under wine (windows emulation under
> > linux)
> > and the creation of processing modules worked pretty well.
> >
> > About the compilations errors you say, it is better that you copy and
> > paste
> > them so we can tell you something about them. If you did modifications to
> > the
> > source code to get it compiled we would be glad if you send them to the
> > list.
> >
> > David.
> >
> > El Friday 28 September 2007 08:26:58 Ali-Akber Saifee va escriure:
> > > Hi there.
> > > I'm looking at using CLAM for a project that my team is looking at.
> >
> > We're
> >
> > > hoping to create a platform independent solution - but our primary
> > > expertise lies in Windows development, therefore we're hoping to create
> >
> > a
> >
> > > working prototype on windows first.
> > >
> > > So here lies my problem :
> > > My dev environment contains:
> > > - Windows SDK ( v6 )
> > > - Visual Studio 2008
> > > - DirectX 10 SDK.
> > >
> > > Clam source 1.1.0
> > >
> > > Using the above + the dependencies claimed by CLAM  - I set up the
> > > scons build environment and immediately ran into problems.
> > >
> > > Problem 1 : scons configure fails on id3lib. looking into the
> > > config.logfile, it shows a few linking errors. I hacked around and
> > > using updated
> > > id3lib binaries (recompiled using VS2008) I got that error to subside.
> > > Subsequently, I got as far as doing a scons - which ended up in compile
> > > time errors with CLAM src's - having mostly to do with 'default int'
> > > declarations etc. After hacking around with the CLAM src's I finally
> > > got
> >
> > it
> >
> > > to build - only to realise that every time I tried to build an example
> > > I got more linking errors.
> > > Problem 2: When I install the NetworkEditor using the installer (1.1.0)
> >
> > if
> >
> > > I try to add any of the Audio I/O processings I get an error message
> > > similar to 'The processing type 'MonoAudioFileReader' is not
> > > supported'. When trying to use the same processing using the clam libs
> > > that I had
> >
> > built
> >
> > > in 'Problem 1' I was getting similar errors (Processing not enumerated
> > > etc).
> > >
> > > Right now, I'll try to check out a svn snapshot of 1.2 and see if that
> > > helps any, but if anyone else has had similar experiences - or resolved
> > > similar problems - I would love to hear. I'm trying to rapidly develop
> > > a prototype - and not being able to get into CLAM's entry point is
> > > quite frustrating :D
> > >
> > > ./Ali