similar to: VS2005 build stability?

Might I make a suggestion? I manage a few rather large cross platform projects which include embedded targets, Windows OS w/ multiple Visual Studio targets (2003, 2005, and 2008), and some Linux flavors. In the past we hand built all the makefiles and manually maintained the Visual Studio project / solution files, which has always been a pain. Recently we've made a successful partial

Hello! I couldn't find any recent discussion of this, so thought I'd post, and I'm not clear who maintains the Win32 build environment or I'd have contacted them directly. I've finally gotten around to turning voice back on in my project, and I'm having issues with obtaining a stable build in VS2005. I've checked out SVN trunk of obb (as libogg) and speex, built

On Thu, Oct 2, 2008 at 12:07 AM, Jean-Marc Valin < jean-marc.valin at usherbrooke.ca> wrote: > Tom Grandgent a ?crit : > > If you remove the project files, I doubt it's going to make things easier > > for anyone. You'll probably just increase the number of questions as > > people struggle to compile using less common and less user-friendly > > methods,

Please note that I'm not advocating CMake as a replacement for autotools or another build environment - what I was postulating is that CMake may provide an easier to maintain option for generation of Visual Studio project and solution files, which unless I'm mistaken the GNU autotools suite does not support. Used in this manner they provide the ability to generate these for at least

Hi, Is is possible to have makefiles, batchfiles, whatever that just calls the command-line compilers and doesn't require this huge amount of per-compiler-version crap? Otherwise, I'm seriously considering removing all those project files from the build since time has proven there's just no way to get them up-to-date. Jean-Marc Alexander Chemeris a ?crit : > Hello, > > On

Tom Grandgent a ?crit : > If you remove the project files, I doubt it's going to make things easier > for anyone. You'll probably just increase the number of questions as > people struggle to compile using less common and less user-friendly > methods, and someone is going to have to maintain that anyway. And how is having out-of-date project files help. > VS users want

Hello, On Wed, Oct 1, 2008 at 8:29 PM, Kerry Bonin <kerry at vscape.com> wrote: > - Anyone else see this? > - Who maintains the Win32 projects (at least the VS2005)? I'd be happy > to work with to solve. > - If nobody is actively maintaining this build, I'd be glad to fix and > contribute back. I'm currently listed as a Win32 build system maintainer, but I

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: speex_vs2008.diff Type: application/octet-stream Size: 165590 bytes Desc: speex_vs2008.diff Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20071127/08917736/speex_vs2008-0001.obj

David Hogan a ?crit : > That said, we don't use the supplied project. We simply compile in > the speex .c files. You could easily replace the Win32 build files > with a readme showing which .c files NOT include in your project > file. > > If you'd like, I'd be happy to produce a readme file on how to make a > VC project file for speex. Although this approach would

On 11/28/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > I think the amount of Windows crap is getting a bit ridiculous. Does > anyone know of a solution to keep things manageable? I mean, the same > autotools files manage the build for Linux PCs, Blackfins and MacOS (and > others). Yet, we need one set of files for each MS compiler version > (good thing they

On Fri, Oct 3, 2008 at 7:15 AM, Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> wrote: > David Hogan a ?crit : >> That said, we don't use the supplied project. We simply compile in >> the speex .c files. You could easily replace the Win32 build files >> with a readme showing which .c files NOT include in your project >> file. >> >> If you'd

Hi I downloaded speex-1.2beta2 from svn.xiph.org/releases/speex and am trying to build the win32/VS2005/libspeex/lipspeex.vcproj When I try to build the Release configuration, I get the following error: LNK1181: cannot open input file '.\Release\medfilter.obj' Trying to build the Debug or Release_Dynamic configurations gives a related error: C1083: cannot open source file:

Hello, I maintain audio processing part of code in sipXtapi -- open-source VoIP library. And when I engaged Speex library, I found that its Windows project files are not up to date and use strange settings. They miss several source files and use single-threaded static runtime libraries. I see no benefits of using static and moreover single-threaded libraries. In the modern world very small amount

On Thu, Oct 2, 2008 at 12:30 AM, Erik de Castro Lopo <mle+la at mega-nerd.com<mle%2Bla at mega-nerd.com> > wrote: > Keith Kyzivat wrote: > > > And Alex has told me that visual studio-built projects cannot link with > > mingw-win32-gcc produced DLLs... > > This is only true when the DLL being called exports C++ name mangled > symbols. Is there a way to get

> Is is possible to have makefiles, batchfiles, whatever that just calls > the command-line compilers and doesn't require this huge amount of > per-compiler-version crap? Otherwise, I'm seriously considering removing > all those project files from the build since time has proven there's > just no way to get them up-to-date. It would actually be fine to just maintain the

Keith Kyzivat wrote: > And Alex has told me that visual studio-built projects cannot link with > mingw-win32-gcc produced DLLs... This is only true when the DLL being called exports C++ name mangled symbols. This is not true for a pure C project like Speex. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo

_CRT_SECURE_NO_DEPRECATE is new for VS2005. Nothing I can do with it in VS2003. Morten Ofstad wrote: > Jeff Cohen wrote: > >> The project files need frequent updating. I cannot maintain VS2005 >> project files, so while they could be distributed with LLVM, they >> will become broken fast. Also, VS2003 and VS2005 project and >> solution files cannot coexist in

The project files need frequent updating. I cannot maintain VS2005 project files, so while they could be distributed with LLVM, they will become broken fast. Also, VS2003 and VS2005 project and solution files cannot coexist in the same directories, further complicating matters. Aaron Gray wrote: > Hi Morten, > > If you can make the VS2005 project files availiable on the net then I

The new property manager doesn't exist in VS2003 either. Don't know where to add it. Chris Lattner wrote: > On Fri, 27 Jan 2006, Jeff Cohen wrote: > >> _CRT_SECURE_NO_DEPRECATE is new for VS2005. Nothing I can do with it >> in VS2003. > > > It shouldn't hurt to define it though, even if VC2003 where it does > nothing. Right? > > -Chris >

Hi, what are the goals of VS2005 support for building LLVM? I'm syncing to the v3 branch and while the branch compiles perfectly with VS2008, there are a significant amount of compile errors and warnings with VS2005 SP1 (8.0.50727.867 with KB926601 SP1, to be precise). I also have the latest WSDK installed. A few months back there were only a few minor issues that I managed to clear up.