search for: solutiondir

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

...lvmdev-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 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...

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]...

I just checked out trunk/vorbis to build the latest libvorbis, 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". ("Release" for the Release configuration) However, for the two build configurations Release_SSE and Release_SSE2, Output Directory is "$(ConfigurationName)" and Intermediate Directory is also &quot...

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.

...Ofstad wrote: > This problem is the motivation for having the _X86TargetMachineModule > symbol in LLVM. I thought this problem was solved by explictly list the object files in the "Additional Dependencies" of the project file? win32/llc/llc.vcproj: AdditionalDependencies="$(SolutionDir)X86\$(IntDir)\X86TargetMachine.obj $(SolutionDir)\CBackend\$(IntDir)\Writer.obj" -- Tzu-Chien Chiu, 3D Graphics Hardware Architect <URL:http://www.csie.nctu.edu.tw/~jwchiu>

...are willing to contribute. I personally will support the autotools based build system and can also support the Makefile.lite build system. > 2) > VC projects contain relative paths such as "..\..\include". Is it better to > leave them as is or to change to something like "$(SolutionDir)include"? That sounds like a good idea. > 3) > Currently there are two ia32 asm files (bitreader_asm.nasm and stream_encoder_asm.nasm) > that are unused and not necessary to compile libFLAC: they offer no speed benefit > and the corresponding functions were commented out (*after*...

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

...> 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 OutputDirectory="$(SolutionDir)objs\$(ConfigurationName)\bin and so on. It also removes OutputFile="..\..\objs\debug\lib\$(ProjectName).lib when possible. Also, in the current version "Whole program optimization" compiler option is set, but the corresponding linker option isn't. From MSDN: "If...

...wo .sln files: current FLAC.sln and new FLAC-vs2013.sln (or FLAC-vs201x.sln? or is it better to rename FLAC.sln to FLAC-vs2005.sln?) What do you think? 2) VC projects contain relative paths such as "..\..\include". Is it better to leave them as is or to change to something like "$(SolutionDir)include"? 3) Currently there are two ia32 asm files (bitreader_asm.nasm and stream_encoder_asm.nasm) that are unused and not necessary to compile libFLAC: they offer no speed benefit and the corresponding functions were commented out (*after* the release of 1.3.0): http://git.xiph.org/?...

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 "$(ConfigurationName)" and Intermediate Directory is also "$ConfigurationName)". How come this is incons...

Hi, I’d just like to interject to say that building within Visual Studio isn’t really that bad. Running the lit tests is a bit painful because the LLVM build tools that are integrated with the build system don’t play nice with msbuild. Particularly, I’ve never been able to actually cancel an invocation of lit or tablegen via visual studio. That said, there is a huge upside to building with

...I asked about unused .nasm files: it's better to do all the changes to .vcproj files first, and only then convert them to .vcxproj. >> VC projects contain relative paths such as "..\..\include". Is it better to >> leave them as is or to change to something like "$(SolutionDir)include"? > > That sounds like a good idea. I opened libFLAC_static.vcproj in a text editor and it turns out that it contains relative paths anyway: <File RelativePath="..\..\include\FLAC\stream_encoder.h"></File> So replacing relative paths in "Additiona...

...and new FLAC-vs2013.sln >(or FLAC-vs201x.sln? or is it better to rename FLAC.sln to FLAC-vs2005.sln?) > >What do you think? > > >2) >VC projects contain relative paths such as "..\..\include". Is it better to >leave them as is or to change to something like "$(SolutionDir)include"? > >3) >Currently there are two ia32 asm files (bitreader_asm.nasm and >stream_encoder_asm.nasm) that are unused and not necessary to compile libFLAC: >they offer no speed benefit and the corresponding functions were commented out >(*after* the release of 1.3.0): &gt...

...used .nasm files: it's better to do all the > changes to .vcproj files first, and only then convert them to .vcxproj. +1 > >> VC projects contain relative paths such as "..\..\include". Is it better to > >> leave them as is or to change to something like "$(SolutionDir)include"? > > > > That sounds like a good idea. > > I opened libFLAC_static.vcproj in a text editor and it turns out that it > contains relative paths anyway: > <File RelativePath="..\..\include\FLAC\stream_encoder.h"></File> > So replacin...

...ithin the .sln script--am I missing 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...

...gt; >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 > u...

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