similar to: vs2005 project file output dir inconsistency

I just checked out trunk/ogg to build the latest libogg, and noticed an inconsistency in the project settings. For the two build configurations Debug and Release, we have as the Output Directory "$(SolutionDir)$(ConfigurationName)", and the Intermediate Directory "Debug". However, for the two build configurations Release_SSE and Release_SSE2, Output Directory is

Razvan Aciu wrote: > As I saw from the mailing list the MSVC 2005 patches were made to take into > account the new files from the development branch, files which are not in > the 2.3 release. So for now the below patch is the only one functional for > the release. If I am wrong, please someone correct me. > > If someone can make a 2005 patch for the release branch, it is ok.

On Sat, Nov 1, 2008 at 2:40 PM, Aymeric Moizard <jack at atosc.org> wrote: > The vcproj file provided for 2005 in 1.2rc1 does not include > _USE_SSE when compiling the project for "Release_SSE". This > define is only used when compiling under "Release_Dynamic_SSE". > > Is this just because the vcproj file is wrong or is it because > this #define must not

Ben Allison wrote ( http://lists.xiph.org/pipermail/flac-dev/2013-March/003793.html ): > The project files could also stand a bit of an overhaul. It would be good > to use project references rather than hardcoding .lib paths into the > linker settings. Done ;) The patch replaces OutputDirectory="..\..\..\..\objs\debug\bin" with

Hi all, It sees that the most serious bug in the flac bug tracker: https://sourceforge.net/p/flac/bugs/413/ has been fixed in git. This fix alone is worth a new release so its time to work towards one. Things I need to do for this new release: * Deal with all current patches on the mailing list. * Review all bugs reported against 1.3.0 on the sf.net. * Testing and coordination of testing

lvqcl wrote: > 1) > Current MSVC solution (FLAC.sln and numerous .vcproj files) was made with > VC2005 Express and doesn't allow to build 64-bit files/libraries. > > IMHO it's time to add 64-bit support for MSVC builds, but AFAIK only Visual Studio > 2012/2013 Express are free and allow to build 64-bit files. > > VS 2005/2008 use .vcproj files, and VS

Dear all, I have just implemented a gstreamer plugin for the Speex AEC, but now I would like to extend it to a multichannel echo cancellation I have been searching documentation about that but I could not find it Where it is? If it doesn't exist? Could you add a short example showing how do you think it should work? or It's "just" necessary to: init the multichannel echo

Hi all, Currently the MSVC project files contain paths using the $(SolutionDir) macro. Unfortunately this means that if you include LLVM in another solution lots of paths are wrong. So I'd like to propose to avoid using the solution relative path macro, and use $(ProjectDir) instead. Does everyone using MSVC agree this would be better? I could post a patch if anyone's interested.

Hello! I wrote a blog post requesting help for Theora on MSVC-syntax assembly. This is my first time speaking for Xiph instead of just myself so please teach me what to do better next time. (Better offlist probably.) My post might contain a few interesting bits for Xiph members as well. It can be found here: http://blog.hartwork.org/?p=86 Sebastian

Hola Nicolas, I'm fine with this change. Chuck. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Nicolas Capens Sent: Friday, July 04, 2008 5:43 AM To: 'LLVM Developers Mailing List' Subject: [LLVMdev] MSVC solution relative paths Hi all, Currently the MSVC project files contain paths

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 > Morten Ofstad wrote: > >> Jeff Cohen wrote: >> >>> The project files need frequent updating. I cannot maintain VS2005 >>>

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 same directories, further complicating matters. The VS2003 project files convert without problems -- you might want to add in

_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

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.

OK, it's not that bad - it's even better than before :) The main issue is RWMutex.inc and the use of PSRWLOCK. This requires _WIN32_WINNT to be >= 0x0600, which is not true for VS2005 SP1. Rather than #define _WIN32_WINNT 0x0600 (the file notes that this should build on all Win32 variants), extending the copy/paste of winbase.h to this works fine: #if defined(__MINGW32__) ||

On Fri, 27 Jan 2006, Jeff Cohen wrote: > The new property manager doesn't exist in VS2003 either. Don't know where to > add it. Isn't there a place to add -D_CRT_SECURE_NO_DEPRECATE for the preprocessor? Isn't this all we are talking about, or am I missing something? -Chris >> On Fri, 27 Jan 2006, Jeff Cohen wrote: >> >>> _CRT_SECURE_NO_DEPRECATE

I don't know. If that's all it was, why is there a special new property manager to set it? Morten will need to explain what to do in VS2003 to make VS2005 happy. Chris Lattner wrote: > On Fri, 27 Jan 2006, Jeff Cohen wrote: > >> The new property manager doesn't exist in VS2003 either. Don't know >> where to add it. > > > Isn't there a place to

Hi Francois, I have all licensed versions of VS at my disposal (the benefits of being a former MS employee) but I'm currently using VS2005 due to specific technical reasons that I can't disclose. The "Getting Started" page states support of 2005 SP1 which, if it's not being maintained, is not true and should be updated. Cheers, - Don ----- Original Message ----- From:

Hi Morten, If you can make the VS2005 project files availiable on the net then I can test them as I have VS2005 now, so then with Chris'es okay then they could be distributed with LLVM. Thanks, Aaron ----- Original Message ----- From: "Morten Ofstad" <morten at hue.no> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Thursday, January 26,