similar to: PATCH for MSVC .sln file (repeat)

Solution file still contained the removed in_flac project causing unnecessary errors on load. -------------- next part -------------- --- FLAC.sln.orig Wed Mar 13 18:23:38 2013 +++ FLAC.sln Sat Mar 16 19:14:43 2013 @@ -57,14 +57,6 @@ Project("{4cefbc7c-c215-11db-8314-080020 {4cefbc89-c215-11db-8314-0800200c9a66} = {4cefbc89-c215-11db-8314-0800200c9a66} EndProjectSection EndProject

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}") =

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

If you look at an .sln file, there's a long sequence of digits associated with every project, something like this 8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942. For the lack of a better word I called it "encoding". After I changed the dependencies between projects in the solution, msvs replaced those numeric sequences by new ones literally for every project in the solution file. The diff now

Hi Dmitri, I know what you are saying, but in the end I think we are lucky if diffs against project files have any meaningful information. Nobody right now assumes responsibility for regularly updating the VS files, so we routinely get patches from different people when they decide to upgrade the project files, and these patches change the .sln files in arbitrary ways. If you have

Hi all, Please, how could I calculate the time that two time segments has in common? Is there any function to perform this calculation? For instance, given four POSIXlt objects... endPeriod<-as.POSIXlt("2008-09-30") startPeriod<-as.POSIXlt("2007-10-01") endProject<-as.POSIXlt("2007-05-31") startProject<-as.POSIXlt("2006-12-01") that limit

On May 17, 2008, at 11:51 PM, Dmitri Makarov wrote: > This in effect adds codegen.lib to the > list of libraries linked into clang.exe and solves all the unresolved > symbol errors in the clang build. I would submit the diff, but it > looks like visual studio changes all the encodings of projects in the > .sln file, so the diff includes a lot of irrelevant lines. Changes all the

Ted, Attached is the diff against TOT. It makes the VS build work for me. Solution/project files work with VS 2005. Project files in clang need not to be modified. As it happens, the solution file for clang is part of the llvm tree ( go figure... ) Thanks Dmitri --- Ted Kremenek <kremenek at apple.com> wrote: > Hi Dmitri, > > I know what you are saying, but in the end I

Ted, Thanks for taking care of this. I found that in order to build clang (in addition to the vcproj changes I posted earlier today) I had to add a dependency such that the clangDriver project depends on the CodeGen (basically the CodeGen checkbox has to be checked in the list of the clangDriver's dependencies). This in effect adds codegen.lib to the list of libraries linked into clang.exe

Hi! Since linux-flashplugin7 r63 is vulnerable according to http://vuxml.FreeBSD.org/7c75d48c-429b-11db-afae-000c6ec775d9.html isn't www/linux-seamonkey vulerable, too (it seems to include 7 r25)? Bye Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Hello R users, I have this regex see [1] for apache log lines. I tried using R to parse some data (only because I wanted to stay in R). A sample line is [2] (a) I saved the line in [1] into "~/tmp/a.txt" and [2] into "/tmp/a.txt" pat <- readLines("~/tmp/a.txt") test <- readLines("/tmp/a.txt") test grep(pat,test) returns integer(0) The same query

I am still using them for llc/llvm-as/opt/llvm-dis/tablegen and a few others. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of steve naroff Sent: Wednesday, January 14, 2009 4:09 PM To: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln Folks, Is anyone still using the Visual

Hi, I just moved to the CMake solution. By the way, the generated libs haven't the same names. In my opinion, we have to choose one way and remove the other one. If it helps, you can put in the win32 directory the result of CMake, or add a script that generate this win32 directory with cmake. Gab > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces

Makslane Araújo Rodrigues <makslane at hotmail.com> writes: > Please, don't remove, I'm using!!! What's preventing you from using CMake? Is there some problem we can solve? -- Oscar

> > I just moved to the CMake solution. By the way, the generated libs > > haven't the same names. > > Which ones? The only difference is that we now generate .lib files > where > .obj were generated on the past, and require a parameter to be passed > to > the linker for including them on the final executable. I was linking with VMCore.lib support.lib

Hi Steve, On Thu, 15 Jan 2009, steve naroff wrote: > For development, CMake is working great for me. I rarely get build > errors related to the project file being out-of-date. > > Is it true that CMake only generates absolute paths? Any idea on the > difficulty of generating relative paths? I consider this a pretty big > obstacle... I did not follow the full-thread, just

Please, don't remove, I'm using!!! Regards, Makslane > From: snaroff at apple.com > To: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu > Date: Wed, 14 Jan 2009 16:09:13 -0800 > Subject: [cfe-dev] win32/llvm.sln, win32/clang.sln > > Folks, > > Is anyone still using the Visual Studio solution files in the win32 > directory? > > If they aren't

Mondada Gabriele <g.mondada at etel.ch> writes: > I just moved to the CMake solution. By the way, the generated libs > haven't the same names. Which ones? The only difference is that we now generate .lib files where .obj were generated on the past, and require a parameter to be passed to the linker for including them on the final executable. > In my opinion, we have to choose

Douglas Gregor <dgregor at apple.com> writes: >>> Please, don't remove, I'm using!!! >> >> What's preventing you from using CMake? >> >> Is there some problem we can solve? > > At some point, we'll need to deal with the testing issue in the CMake > build system. Clang, for example, uses some GNU make magic to run its > tests,

On Jan 15, 2009, at 8:43 AM, Óscar Fuentes wrote: > Makslane Araújo Rodrigues > <makslane at hotmail.com> writes: > >> Please, don't remove, I'm using!!! > > What's preventing you from using CMake? > > Is there some problem we can solve? At some point, we'll need to deal with the testing issue in the CMake build system. Clang, for example, uses