search for: projectdir

...roj b/win32/VS2015/celt.vcxproj index 273ee4d..1499f56 100644 --- a/win32/VS2015/celt.vcxproj +++ b/win32/VS2015/celt.vcxproj @@ -249,8 +249,10 @@ <GenerateDebugInformation>true</GenerateDebugInformation> </Link> <PreBuildEvent> - <Command>"$(ProjectDir)..\..\win32\genversion.bat" "$(ProjectDir)..\..\win32\version.h" PACKAGE_VERSION</Command> - <Message>Generating version.h</Message> + <Command> + </Command> + <Message> + </Message> </PreBuildEvent> &...

...<PreprocessorDefinitions>HAVE_CONFIG_H;WIN32;_DEBUG;_LIB;%(PreprocessorDefinitions)</PreprocessorDefinitions> - <AdditionalIncludeDirectories>..\;..\..\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories> + <AdditionalIncludeDirectories>$(ProjectDir)\..\;$(ProjectDir)\..\..\include;$(ProjectDir)\..\..\celt;$(ProjectDir)\..\..\silk;$(ProjectDir)\..\..\silk\float;$(ProjectDir)\..\..\silk\fixed;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories> <RuntimeLibrary>MultiThreadedDebug</RuntimeLibrary> </ClCo...

...<PreprocessorDefinitions>HAVE_CONFIG_H;WIN32;_DEBUG;_LIB;%(PreprocessorDefinitions)</PreprocessorDefinitions> - <AdditionalIncludeDirectories>..\;..\..\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories> + <AdditionalIncludeDirectories>$(ProjectDir)\..\;$(ProjectDir)\..\..\include;$(ProjectDir)\..\..\celt;$(ProjectDir)\..\..\silk;$(ProjectDir)\..\..\silk\float;$(ProjectDir)\..\..\silk\fixed;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories> <RuntimeLibrary>MultiThreadedDebug</RuntimeLibrary> </ClCo...

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. Cheers, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080704/5217690b/att...

...solution relative paths 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... Cheers, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080707/460f401c/a...

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 relative pa...

Hi All, Since I continue to base my work on top of Jonathan's patch, and my previous Ne10 fft/ifft/mdct_forward/backward patches, I thought it would be better to just post all new patches as a patch series. Please let me know if anyone disagrees with this approach. You can see wip branch of all latest patches at https://git.linaro.org/people/viswanath.puttagunta/opus.git Branch:

Hi Timothy, As I mentioned earlier [1], I now fixed compile issues with fixed point and resubmitting the patch. I also have new patch that does intrinsics optimizations for celt_pitch_xcorr targetting aarch64. You can find my latest work-in-progress branch at [2] For reference, you can use the Ne10 pre-built libraries at [3] Note that I am working with Phil at ARM to get my patch at [4]

...s added. We think the problem is with the R code to run the covariate data analysis. We have the control stream, R code (along with the error), and data attached. If anyone can help we would really appreciate it. Thank you very much. Michael R Code: # load MItools from within R library(MItools) ProjectDir <- "~/EssentialsOpenCourseware/continuous_PKPD/Examples" NMcom <- "nm6osxg77big.pl" cov <- c("AGE", "BW") # run NONMEM using 3032.ctl NONR(ProjectDir=ProjectDir, NMcom=NMcom, dvname="Test (mcg/L)", diag=1, covplt=1,...

Hi All, As per Timothy's suggestion, disabling mdct_forward for fixed point. Only effects armv7,armv8: Extend fixed fft NE10 optimizations to mdct Rest of patches are same as in [1] For reference, latest wip code for opus is at [2] Still working with NE10 team at ARM to get corner cases of mdct_forward. Will update with another patch when issue in NE10 gets fixed. Regards, Vish [1]:

Hi All, Changes from RFC v2 [1] armv7,armv8: Extend fixed fft NE10 optimizations to mdct - Overflow issue fixed by Phil at ARM. Ne10 wip at [2]. Should be upstream soon. - So, re-enabled using fixed fft for mdct_forward which was disabled in RFCv2 armv7,armv8: Optimize fixed point fft using NE10 library - Thanks to Jonathan Lennox, fixed some build fixes on iOS and some copy-paste errors Rest

Hello Timothy / Jean-Marc / opus-dev, This patch series is follow up on work I posted on [1]. In addition to what was posted on [1], this patch series mainly integrates Fixed point FFT implementations in NE10 library into opus. You can view my opus wip code at [2]. Note that while I found some issues both with the NE10 library(fixed fft) and with Linaro toolchain (armv8 intrinsics), the work

...(list=ls()) # loadEcgFiles <- function(Dir=".") { Dir <- "."; txtfiles <- list.files(paste(Dir),'.txt$'); ecg = data.frame(ncol=1); len = length(txtfiles); for (i in 1:5 ) { # i <- 1; filename = paste(projectDir, "/" , txtfiles[i],sep=''); sample = read.table(filename, nrow=75000); sampleName = filename; sampleName=gsub("./", "",sampleName); sampleName=gsub(".txt", "", sampleName); temp <- sample$V2...

...a >pre-build step someplace? When config.h.in is hit in the build of configure the configure project, the configure.h file from the win32 directory is copied to main llvm\Config\Config.h. The script in the sln file is: copy "$(InputPath)"+"$(SolutionDir)config.h" "$(ProjectDir)..\llvm\Config\config.h" configured as a custom build step in the solution file. Is that not firing from the command line compilation of the sln? The file in the win32 directory is the config.h file that's ultimately used when compiling everything under VStudio. That it implies that it...

...> When config.h.in is hit in the build of configure the configure > project, > the configure.h file from the win32 directory is copied to main > llvm\Config\Config.h. The script in the sln file is: > > copy "$(InputPath)"+"$(SolutionDir)config.h" > "$(ProjectDir)..\llvm\Config\config.h" > > configured as a custom build step in the solution file. Is that not > firing from the command line compilation of the sln? > > The file in the win32 directory is the config.h file that's ultimately > used when compiling everything under VSt...

More on this: Walking through the projects slowly: (*) "Configure" builds with no problem. (*) "support" fails: C:\Prg\llvm-2.2\llvm-2.2\win32>msbuild llvm.sln /t:Build Microsoft (R) Build Engine Version 2.0.50727.1433 [Microsoft .NET Framework, Version 2.0.50727.1433] Copyright (C) Microsoft Corporation 2005. All rights reserved. Build started 2/18/2008 12:07:45 AM.

By the way, somebody (I think it was Chuck, but I don't remember for certain) was asking for the BuildLog.htm from building the llvm.sln file under VS 2005 SP1 for diagnostic purposes; right now the SLN is configured to produce a new BuildLog for each and every one of the projects inside the solution. I don't know who's responsible for this guy, but that's probably not the best way

[This email is either empty or too large to be displayed at this time]