similar to: [PATCH 3/3] solution/project files for MSVS 2010 and newer

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

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

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 ++++++++++++++++-

On 2013-09-30 4:53 PM, Erik de Castro Lopo wrote: > I'd be keen to have the windows build automatically do the sanest possible thing, > preferably with anyone having to copy files. The way we've been doing the Opus stuff is to have the project files expect a build in a parallel checkout. so: c:\dev\flac\FLAC.sln expects to find an ogg build in c:\dev\ogg\win32\VS2010\ Not as

Recently I downloaded MSVC++2005 Express Edition and it turns out that it wasn't possible to compile all files without several changes: 1) FLAC.sln has one extra "EndProject" line --- a\FLAC.sln 2013-06-17 11:57:09.000000000 +0400 +++ b\FLAC.sln 2013-08-16 20:19:34.630486700 +0400 @@ -157,7 +157,6 @@ EndProject Project("{4cefbc7c-c215-11db-8314-0800200c9a66}") =

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

Here are a couple of representative errors. C:\Dev\upstream\gitmono is where I keep my clone. "C:\Dev\upstream\gitmono\wbuild\ALL_BUILD.vcxproj" (Rebuild target) (1) -> "C:\Dev\upstream\gitmono\wbuild\unittests\Support\DynamicLibrary\SecondLib.vcxproj" (default target) (170:2) -> c1xx : fatal error C1083: Cannot open source file:

I think MSBuild isn't capable of re-running cmake and then reloading the project files when CMakeLists.txt changes. It re-runs cmake, but then continues the build with the stale projects. That probably explains the "PipSqueek.cxx doesn't exist" errors. As for the link error, it could also be caused by things like a file rename not getting picked up by MSBuild. The fix is

I have the git monorepo, and Visual Studio 2015. I am finding that running a build from the command line with msbuild (as a nightly job) invariably fails on the first try, and succeeds on a retry. The first msbuild command looks like this: msbuild ALL_BUILD.vcxproj /p:Configuration="RelWithDebInfo" /m:6 /t:Rebuild This appears to compile everything okay, but invariably fails with

msbuild is is able to re-run cmake if a CMakeLists.txt changes. CMake adds a special project "ZERO_CHECK" that does this. However, I am not sure it runs when invoking on the individual projects instead of the solution. Try the cmake --build command, which should output the following: > cmake --build . --target opt CMake is re-running because

What kind of missing symbols are you getting? I had to work around dependencies for a Mingw32 build. See https://reviews.llvm.org/D44650 On Wed, May 16, 2018, 13:13 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I have the git monorepo, and Visual Studio 2015. I am finding that > running a build from the command line with msbuild (as a nightly job) > invariably fails on the

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

first: thank you for helping out >I might try compiling your source from the VS's Developer Command Prompt: >cmake --build . --target Fibonacci >Does this work? call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat" cd llvm-build cmake --build . --config Debug --target Fibonacci building Fibonacci example works BUT

With VS2013 I found that editing a CMakeLists.txt file caused CMake to be re-run successfully and the build to also continue successfully, but since I switched to VS2015 the CMake re-run occurs - apparently successfully, but more often than not the build failed afterwards from either the IDE and from MSBuild. Since I seldom change the CMakeLists.txt files, I simply do a clean CMake configuration

This patch allows MSVS to use M_LN2 const defined in math.h -------------- next part -------------- A non-text attachment was scrubbed... Name: mathln2.patch Type: application/octet-stream Size: 963 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130904/14cd34db/attachment.obj

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

>From my own experience this is what I think happens when building the whole solution through Visual Studio's UI. This also happens for building individual projects. I assume something similar happens when building via the command-line, but I rarely do that, so I can't be certain. 1) Visual Studio/MSBuild (I don't know which, but probably MSBuild) determines the dependency graph of

I cannot see my post with a patch for FLAC.sln (too long?) Here I repeat this message, with patch file compressed to .zip: --------------------------------------------------------------- Every time I open current FLAC.sln in MSVS 2005, it rewrites (fixes) this file. The diff between new and old files is attached. Current version has several problems: a) it has one extra EndProject line. b) it

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Is there not a later free (as in free beer) version? There are also 2008, 2010 and 2012 versions. VS2012 Express requires Win7 to run (though it can create programs compatible with WinXP). VS2010 Express works on WinXP. It is possible to compile x86-64 programs with it, but it requires Platform SDK (also free). VS2005 and 2008

It looks like building ZERO_CHECK first to reconstruct the project files as needed, then running msbuild a second time to do the actual build, has solved the problem. At least, last night's run didn't take the usual two tries. Running msbuild twice is a little bit simpler than running cmake explicitly, the way I have my scripts set up, but I'm sure that would work as well. Thanks