similar to: [LLVMdev] sys::path::system_temp_directory vs. sys::fs::createTemporaryFile

I have a few concerns: 1. GetTempPathW is buggy, we should be manually using GetEnvironmentVariableW with TMP, TEMP and USERPROFILE arguments and use the first that exists. 2. We should make sure that the platform specific pieces live in their respective Path.inc files. On Thu, Jul 24, 2014 at 9:44 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On

On Jul 25, 2014, at 13:44 , Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 25 July 2014 16:31, David Majnemer <david.majnemer at gmail.com> wrote: >> I have a few concerns: >> 1. GetTempPathW is buggy, we should be manually using >> GetEnvironmentVariableW with TMP, TEMP and USERPROFILE arguments and use the >> first that exists. >> 2. We

On 25 July 2014 17:57, David Majnemer <david.majnemer at gmail.com> wrote: > To be clear, I don't think we need both; I'd like for us to drop one of > them. I just want to make sure that that the final state, post merge, works > well on all of our platforms. :) Cool. The attached patch removes TempDir. It passes all tests, but the OS X case looks a bit suspicious. I first

> It looks like OS X always has TMPDIR set these days (to the value of > _CS_DARWIN_USER_TEMP_DIR), so I think we should just go with TMPDIR if it's > set and non-empty, and then fall back to confstr. However, we should not be > using TMPDIR if ErasedOnReboot is false (i.e. if we'd prefer > _CS_DARWIN_USER_CACHE_DIR). Unfortunately there's no canonical environment >

> Well, that changes behavior on Linux; previously it did honor TMPDIR when > looking for a cache directory. Is that okay? (The Windows version is also > honoring TEMP in this case.) I *think* that is a bug fix. I don't have those env variables set on my linux machine (fedora 20), but I don't remember seeing them pointing to anything but /tmp in the past and that is even in

Hi, llvm::sys::path allows the user to query "known directory" paths: temp, cache, home. I was tweaking this area a bit for some time. I would like to propose a small redesign. What we have so far? home_directory() tries to return what it promises. No issues with that. system_temp_directory(true) returns a path to a directory that can be erased on reboot. On Linux it is usually /tmp.

On Mon, Nov 23, 2015 at 3:27 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 23 November 2015 at 15:11, Aaron Ballman <aaron.ballman at gmail.com> wrote: >> On Mon, Nov 23, 2015 at 3:07 PM, Rafael Espíndola >> <rafael.espindola at gmail.com> wrote: >>>> We appear to use both system_temp_directory(true) and >>>>

On Mon, Nov 23, 2015 at 3:07 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> We appear to use both system_temp_directory(true) and >> system_temp_directory(false) in ways that seem like they could matter. >> For instance, modules uses a temp directory that does not get erased >> on reboot, possibly for performance reasons. Do we gain something from

What are the various option we have in setting tmp dir. I can't use the default var/tmp, and I am looking to pass the dir during compiler invocation as an arg. any help is great. Thanks Ramakrishna -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160324/263cba7a/attachment.html>

Hi, LLVM will look for the following environment variables to be set, and if not it will use /var/tmp: TMPDIR, TMP, TEMP, TEMPDIR You should be able to override its behaviour by setting one of those. Cheers, James On Thu, 24 Mar 2016 at 11:21 Ramakrishna Mallireddy via llvm-dev < llvm-dev at lists.llvm.org> wrote: > What are the various option we have in setting tmp dir. > >

I'm trying to install DAZ Studio under Wine and immediately after the splash screen it crashes out and I get a window with the following message: > Error creating directory C:/Program Files/***unknown variable system_temp_directory*** The DAZ Studio version is 3.0.1.135 for Windows. I'm running Wine 1.1.12 under Ubuntu 9.04 with GNOME 2.26.1. My video card is an nVidia GeForce

>From: Jeff Cohen Date: Wed, 26 Jan 2005 19:47:44 -0800 > >Fixed. Yes, now it isn't the path. I've recorded this trace: ------------------------- llvm[3]: Building Debug Bytecode Archive libc.bca /bin/rm -f /C/projects/build/MinGW/llvm-4-1/Debug/lib/libc.bca /C/projects/build/MinGW/llvm-4-1/Debug/bin/llvm-ar rcsf /C/projects/build/MinGW/llvm-4-1/Debug/lib/libc.bca

On Thu, 2005-01-27 at 13:16, Henrik Bach wrote: > c:\projects\build\MinGW\llvm-4-1\Debug\bin\llvm-ar.exe: > c:/projects/build/MinGW/llvm-4-1/Debug/lib/libc.bca-000000: Can't destroy > file (hb:2): The process cannot access the file because it is being used by > another process. > make[3]: *** [/C/projects/build/MinGW/llvm-4-1/Debug/lib/libc.bca] Error 2 >

Hi Jake, About a year ago in commit 5049c3422d26b2b68877307c41b35d7e6aae3235, you attempted to solve a race in llvm-objcopy. What was the race? I ask because unless "last change wins" is the result you want, then the race isn't solved. The problem is that `sys::fs::rename` is just a thin wrapper around POSIX semantics, and replacing an existing file is not an error. Dave

Hi Steven, Look at my replies inline (below your comments). Katya. From: stevenwu at apple.com <stevenwu at apple.com> Sent: Thursday, March 22, 2018 4:46 PM To: Romanova, Katya <katya.romanova at sony.com> Cc: Teresa Johnson <tejohnson at google.com>; Mehdi AMINI <joker.eph at gmail.com>; Rafael Avila de Espindola <rafael.espindola at gmail.com>; Peter Collingbourne

Hi Katya Thanks for investigating this. Here is my thought inline. > On Mar 22, 2018, at 1:32 AM, katya.romanova at sony.com wrote: > > > Hello, > > I am sending the following proposal to discuss issues and solutions regarding data races in concurrent ThinLTO processes. > > This caught my attention when we encountered a race condition in ThinLTO with caching. >

Hi Peter, Thank you for the clarification ☺. I’m sure you have a very good understanding of how much efforts it will take to write a patch for legacy C LTO to implement caching the same way it’s done in new C++ LTO API. How easy/difficult do you think it will be (very roughly, in LOC)? Do you anticipate that a lot of existing legacy C LTO infrastructure will have to be rewritten? Could this also

On Mon, Mar 26, 2018 at 6:03 PM, <katya.romanova at sony.com> wrote: > Hi Steven, > > Look at my replies inline (below your comments). > > Katya. > > > > *From:* stevenwu at apple.com <stevenwu at apple.com> > *Sent:* Thursday, March 22, 2018 4:46 PM > *To:* Romanova, Katya <katya.romanova at sony.com> > *Cc:* Teresa Johnson <tejohnson at

François, thanks for the patches so far. This morning I pushed: https://github.com/libguestfs/nbdkit/commit/e26fb6cea3fdba13b5472daf6767e76abacd8d03 build: add missing #include "byte-swapping.h" https://github.com/libguestfs/nbdkit/commit/b962272a561bfed087316d24b7d510e4ab29a985 build: more fallbacks for mkostemp The iconv patch makes iconv a requirement. I don't know

> On Mar 26, 2018, at 6:03 PM, katya.romanova at sony.com wrote: > > Hi Steven, > Look at my replies inline (below your comments). > Katya. > > From: stevenwu at apple.com <mailto:stevenwu at apple.com> <stevenwu at apple.com <mailto:stevenwu at apple.com>> > Sent: Thursday, March 22, 2018 4:46 PM > To: Romanova, Katya <katya.romanova at sony.com