similar to: [LLVMdev] Pass is not automatically registered

Avoids trying to create and replace version.h more than once which led to file-locking errors with multicore builds. --- Makefile.am | 1 + win32/VS2015/celt.vcxproj | 48 +++++++++++++++++--------- win32/VS2015/generate_version.vcxproj | 65 +++++++++++++++++++++++++++++++++++ win32/VS2015/opus.sln | 32 ++++++++++++++++-

Morten, I've applied these patches. Thanks for the updates! Reid. On Mon, 2004-11-15 at 01:26, Morten Ofstad wrote: > Hi, > > when I updated the sources today there were several small problems that > stopped the windows version from compiling, here are the patches > > m. > > > ______________________________________________________________________ > Index:

On Fri, 3 Dec 2004, Reid Spencer wrote: > Could someone please apply this patch to the Win32 support so that > Morten and Jeff can handle the recent changes? I can't do it because > I"m on the road with only email access. I'd be happy to do it. Can someone send me the patch as an attachment off-list? -Chris > > <Tool > >

Could someone please apply this patch to the Win32 support so that Morten and Jeff can handle the recent changes? I can't do it because I"m on the road with only email access. Thanks, Reid. -----Forwarded Message----- > From: Morten Ofstad <morten at hue.no> > To: Reid Spencer <reid at x10sys.com> > Subject: Updated LLVM Visual Studio project files > Date: Thu,

Erik de Castro Lopo wrote: >> VS 2005/2008 use .vcproj files, and VS 2010/2012/2013 use .vcxproj >> and .vcxproj.filters files, so it's possible to have two sets of >> MSVS solution files: one for 2005/2008 and another for 2010/2012/2013. >> >> But there will be two .sln files: current FLAC.sln and new FLAC-vs2013.sln >> (or FLAC-vs201x.sln? or is it better

Erik de Castro Lopo wrote: > 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

On Thu, 19 Jun 2014 05:00:39 +0400 lvqcl <lvqcl.mail at gmail.com> wrote: >Erik de Castro Lopo wrote: > >> 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

I tried to compile FLAC on Windows (the winamp2 plugin as a test) and I encoutered a problem. The stat() function and the associated structure doesn't exist on Windows (Visual Studio 5/6). But _stat and the structure with the same name does exist. So would it be possible to change stat() and struct stat ? I did the following in the code : #define STAT(x,y) _stat(x,y) typedef struct stat

The BGL (Boost Graph Library) defines tie(), which is exactly what the tie() defined in STLExtras.h. The header files of GBL use boost::tie(), and other boost libraries use boost::tie() too. How to resolve the ambiguity for compiler? -- Tzu-Chien Chiu, 3D Graphics Hardware Architect <URL:http://www.csie.nctu.edu.tw/~jwchiu>

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

I am not sure if my problem is similar to: http://lists.cs.uiuc.edu/pipermail/llvmdev/2003-December/000715.html It seems that the constructor of the static global pass object isn't called: lib/CodeGen/DependenceAnalyzer.cpp: static RegisterAnalysis<DependenceAnalyzer> X("depana", "Dependence Analysis"); I traced into struct RegisterAnalysis ctor, but my pass

lvqcl wrote: > Audacity still uses VS2008 and slowly tries to migrate to VS2012. > But as stated at <http://wiki.audacityteam.org/wiki/Developing_On_Windows>, > "Audacity is currently a 32-bit only application". So it doesn't need > 64-bit builds. > Currently its trunk contains 'audacity.sln' made with Visual C++ Express 2008 > and

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

The attached patch cleans up Opus's x86 intrinsics configury. It: * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in

Hi Chuck et al, I've attached a patch which replaces all $(SolutionDir) macros with $(ProjectDir)..\ in revision 53549's MSVC project files. Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chuck Rose III Sent: Monday, 07 July, 2008 20:17 To: LLVM Developers Mailing List Subject: Re: [LLVMdev] MSVC solution

I have got the latest CVS release of LLVM. And built the Win32 MS VC++ 2003 port with modifications for MS VC++ 2005. Do bear in mind the Visual Studio ports are by no means complete, and are on going. Microsoft Visual Studio 2005 Beta (codename Whidbey) can be got from Microsoft Beta program nearly for free; the cost of postage from :-

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.

srs <skaflotten at gmail.com> writes: >>> While testing my compiler on win32 in JIT mode, I ran into a couple of >>> issues: >>> >>> 1. I linked the compiler with the lib files resulting from the cmake >>> created VS.NET build. While everything built just fine, the >>> ExecutionEngine::create call always returned NULL. The fix was to

2008/12/30 srs <skaflotten at gmail.com> > Óscar Fuentes wrote: > > srs <skaflotten at gmail.com> writes: > > > > > >>>> While testing my compiler on win32 in JIT mode, I ran into a couple of > >>>> issues: > >>>> > >>>> 1. I linked the compiler with the lib files resulting from the cmake >

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