search for: gregbedwel

On Wed, Oct 8, 2014 at 12:17 PM, Greg Bedwell <gregbedwell at gmail.com> wrote: > Hi, > > To follow up from Paul last week: > >> I'm expecting to have our internal builds switched over later this >> week. Our investigations have shown no problems. > > We've now updated our internal builds from 2012.4 (cl.exe 17.0....

...ve no other major users who require VS 2012 support, I think it's reasonable to officially switch now. We might want to wait for 3.6 to go out the door, just to reduce possible issues with porting fixes, but that may be overly cautious. ~Aaron On Wed, Jan 28, 2015 at 7:16 AM, Greg Bedwell <gregbedwell at gmail.com> wrote: > This thread seems to have stalled again without resolution :). Is there > anything else left blocking this change? We've had our PS4 toolchain builds > switched over to VS2013 since I reported back in October without any issues. > > -Greg > > On...

On Mon, Feb 9, 2015 at 8:36 AM, Greg Bedwell <gregbedwell at gmail.com> wrote: > We've just encountered an issue with ninja and VS2013 when using versions of > CMake prior to 2.8.12.1. This isn't a combination that we typically use so > we've not run into it previously in our own builds. It isn't specifically > tied to up...

On Fri, Jul 31, 2015 at 9:09 AM, Greg Bedwell <gregbedwell at gmail.com> wrote: > It sounds like there are no objections to jumping to Windows 7 as the > baseline. Is it worth getting a note added to the next LLVM weekly to give > the potential change a bit of a wider viewership before going ahead with it > or are we in a position to just...

...targets They are pre windows 7 and only support 32bit x86 targets mingw-w64 has been maintained to support newer api's and now supports x64 and arm. On Fri, Jul 31, 2015 at 2:34 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Fri, Jul 31, 2015 at 9:09 AM, Greg Bedwell <gregbedwell at gmail.com> > wrote: > > It sounds like there are no objections to jumping to Windows 7 as the > > baseline. Is it worth getting a note added to the next LLVM weekly to > give > > the potential change a bit of a wider viewership before going ahead with > it > &g...

...VS 2012 support, I think > it's reasonable to officially switch now. We might want to wait for > 3.6 to go out the door, just to reduce possible issues with porting > fixes, but that may be overly cautious. > > ~Aaron > > On Wed, Jan 28, 2015 at 7:16 AM, Greg Bedwell <gregbedwell at gmail.com> wrote: >> This thread seems to have stalled again without resolution :). Is there >> anything else left blocking this change? We've had our PS4 toolchain builds >> switched over to VS2013 since I reported back in October without any issues. >> >&g...

...only support 32bit x86 targets > > mingw-w64 has been maintained to support newer api's and now supports x64 > and arm. > > On Fri, Jul 31, 2015 at 2:34 PM, Aaron Ballman <aaron at aaronballman.com> > wrote: > >> On Fri, Jul 31, 2015 at 9:09 AM, Greg Bedwell <gregbedwell at gmail.com> >> wrote: >> > It sounds like there are no objections to jumping to Windows 7 as the >> > baseline. Is it worth getting a note added to the next LLVM weekly to >> give >> > the potential change a bit of a wider viewership before going ahead...

...e. > > I think it's reasonable to switch to Windows 7 at this point. Vista's > mainstream support ended in 2012 and only has extended support until > 2017, so it's sunsetting already. > > ~Aaron > > > > > On Mon, Jul 13, 2015 at 2:28 PM, Greg Bedwell <gregbedwell at gmail.com> > wrote: > >> > >> Hi all, > >> > >> It looks like this conversation stalled. I have a local patch that I'd > >> like to send upstream (automatically generating Windows crash dumps on > >> clang/LLVM crashes) that makes...

...s reasonable to switch to Windows 7 at this point. Vista's >> mainstream support ended in 2012 and only has extended support until >> 2017, so it's sunsetting already. >> >> ~Aaron >> >> > >> > On Mon, Jul 13, 2015 at 2:28 PM, Greg Bedwell <gregbedwell at gmail.com> >> wrote: >> >> >> >> Hi all, >> >> >> >> It looks like this conversation stalled. I have a local patch that I'd >> >> like to send upstream (automatically generating Windows crash dumps on >> >> cl...

...gt;> >> mingw-w64 has been maintained to support newer api's and now supports x64 >> and arm. >> >> On Fri, Jul 31, 2015 at 2:34 PM, Aaron Ballman <aaron at aaronballman.com> >> wrote: >> >>> On Fri, Jul 31, 2015 at 9:09 AM, Greg Bedwell <gregbedwell at gmail.com> >>> wrote: >>> > It sounds like there are no objections to jumping to Windows 7 as the >>> > baseline. Is it worth getting a note added to the next LLVM weekly to >>> give >>> > the potential change a bit of a wider viewership...

...est supported Windows version as David suggested? I think we should document 7 as the recommended baseline. After we start using some of the newer APIs, we can see if users complain and evaluate the burden of maintaining Vista support at that time. On Mon, Jul 13, 2015 at 2:28 PM, Greg Bedwell <gregbedwell at gmail.com> wrote: > Hi all, > > It looks like this conversation stalled. I have a local patch that I'd > like to send upstream (automatically generating Windows crash dumps on > clang/LLVM crashes) that makes use of a Windows API function that requires > _WIN32_WINNT...

...he procedures involved. I may try that again to see If I have some luck > though. It’s a pity that LLVM is not particularly friendly with familiar > IDEs such as xCode on macs and Visual Studio on windows. > > > > John > > > > On 30 Jun 2019, at 17:43, Greg Bedwell <gregbedwell at gmail.com> wrote: > > > > This is also the case with the Visual Studio generators. Custom commands > in a single cmake file essentially get written out line by line into a > single batch file that gets processed as a custom build step. In the VS > case this means that it...

...uld document 7 as the >>> recommended baseline. After we start using some of the newer APIs, we can >>> see if users complain and evaluate the burden of maintaining Vista support >>> at that time. >>> >>> On Mon, Jul 13, 2015 at 2:28 PM, Greg Bedwell <gregbedwell at gmail.com> wrote: >>>> >>>> Hi all, >>>> >>>> It looks like this conversation stalled. I have a local patch that I'd >>>> like to send upstream (automatically generating Windows crash dumps on >>>> clang/LLVM crashe...

...then the verifier (or some other pass, I forget how it's phrased) can check if the version matches the current LLVM's debug info metadata version, and if it doesn't match, it strips out all the debug info metadata. > > Alex > > On Sep 27, 2014, at 3:19 AM, Greg Bedwell <gregbedwell at gmail.com> wrote: > > As I understand it, the bitcode compatibility promise doesn't extend as > far as debug info metadata (happy to be wrong here!). I think we have a > usecase where need to guarantee that debug information from any two > arbitrary bitcode files going in...

...miliarised at all with the procedures involved. I may try that again to see If I have some luck though. It’s a pity that LLVM is not particularly friendly with familiar IDEs such as xCode on macs and Visual Studio on windows. > > John > >> On 30 Jun 2019, at 17:43, Greg Bedwell <gregbedwell at gmail.com> wrote: >> >> This is also the case with the Visual Studio generators. Custom commands in a single cmake file essentially get written out line by line into a single batch file that gets processed as a custom build step. In the VS case this means that it can, for exampl...

...some luck though. It’s a pity >> that LLVM is not particularly friendly with familiar IDEs >> such as xCode on macs and Visual Studio on windows. >> >> John >> >> On 30 Jun 2019, at 17:43, Greg Bedwell >> <gregbedwell at gmail.com <mailto:gregbedwell at gmail.com>> wrote: >> >> This is also the case with the Visual Studio generators. >> Custom commands in a single cmake file essentially get >> written out line by line into a single batch file...

...ty >>> that LLVM is not particularly friendly with familiar IDEs >>> such as xCode on macs and Visual Studio on windows. >>> >>> John >>> >>> On 30 Jun 2019, at 17:43, Greg Bedwell >>> <gregbedwell at gmail.com <mailto:gregbedwell at gmail.com>> wrote: >>> >>> This is also the case with the Visual Studio generators. >>> Custom commands in a single cmake file essentially get >>> written out line by line into a si...

...pass, I forget > how it's phrased) can check if the version matches the current LLVM's debug > info metadata version, and if it doesn't match, it strips out all the debug > info metadata. > > > > > Alex > > > On Sep 27, 2014, at 3:19 AM, Greg Bedwell <gregbedwell at gmail.com> wrote: > > As I understand it, the bitcode compatibility promise doesn't extend as > far as debug info metadata (happy to be wrong here!). I think we have a > usecase where need to guarantee that debug information from any two > arbitrary bitcode files going i...

We formally support our toolchain only on Windows 7 onward, so it's okay with us. (Please make sure this goes in the release notes when you start doing something not supported in XP and/or Vista.) --paulr From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Jim Rowan Sent: Friday, October 31, 2014 1:05 PM To: Reid Kleckner Cc: LLVM Developers Mailing List

Hello everyone, LLVM buildmaster is back to work. Two slaves remain off for now as they produce a lot of warnings and their log files are way too big. The next builds have full logs available. Hope this helps to fix this issue: http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/8716 http://lab.llvm.org:8011/builders/clang-with-thin-lto-windows/builds/2645 Thanks Galina