Thank you! It seems that your commit have fixed the bug - it haven't been
reproduced on `lldb-x64-windows-ninja` since your commit.
On Thu, Dec 6, 2018 at 9:45 PM Zachary Turner wrote:
> Hopefully fixed in r348511. I went with the approach of concatenating the
> executable file name, for two re
Hopefully fixed in r348511. I went with the approach of concatenating the
executable file name, for two reasons. First, it's easier, since dealing
with the tmpfile module and mkstemp and sorts has its own set of
complexities and issues. Secondly, because it means the build artifacts
will still b
I am in favor of unique filenames because it will guarantee we avoid any
problems like this in the future, but in most cases, as long as the names are
unique *in the test suite*, that should be sufficient. So I don’t have any
objections to Zachary’s approach of making the filenames unique enough
Yea that sounds reasonable
On Thu, Dec 6, 2018 at 1:07 AM Pavel Labath wrote:
> On 06/12/2018 09:25, Aleksandr Urakov via lldb-commits wrote:
> >
> > I thought about what Stella have said, and it seems that I have found a
> > good solution for this. We can use something like `tempfile`
> > (https
On 06/12/2018 09:25, Aleksandr Urakov via lldb-commits wrote:
I thought about what Stella have said, and it seems that I have found a
good solution for this. We can use something like `tempfile`
(https://docs.python.org/3.7/library/tempfile.html) for every internally
generated file of the scr
Yes, this solution would solve the current problem. But theoretically the
uniqueness may be defined by the directory, where the file is located, not
by the name. It looks very unlikely, but who knows...
I thought about what Stella have said, and it seems that I have found a
good solution for this.
I was thinking that we could just automatically compute the output file
names as:
os.path.join(out_dir, basename(output_file) + '.' + basename(input_file) +
'.obj')
Currently it's just
os.path.join(out_dir, basename(input_file) + '.obj')
which is why I think the problem occurs.
On Wed, Dec 5,
I think with all the tests running in parallel we should err on the side of
having unique names for everything automatically generated.
From: Aleksandr Urakov
Sent: Wednesday, December 5, 2018 12:48 PM
To: Zachary Turner
Cc: reviews+d54942+public+2603ca548f36d...@reviews.llvm.org; Stella Stamen
With such solution there would be even no need to change the current
commit. But I'm not sure that it's trivial to do - the output file name may
contain path with directories. May be we can replace slashes with
underscores in the output file path and concatenate it with the object file
name? Or eve
It is not possible to specify object file name in compile and link mode.
But perhaps we can just change the default object file name to include
something from the output file as well
On Wed, Dec 5, 2018 at 12:26 PM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrote:
> aleksandr.ura
Ok, thanks!
On Wed, Dec 5, 2018 at 6:06 PM Zachary Turner wrote:
> Yes, if the tests pass for you with current builder, please commit
> On Wed, Dec 5, 2018 at 6:06 AM Aleksandr Urakov via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> aleksandr.urakov added a comment.
>>
>> It seems that
Yes, if the tests pass for you with current builder, please commit
On Wed, Dec 5, 2018 at 6:06 AM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrote:
> aleksandr.urakov added a comment.
>
> It seems that all the reviews this one depends on are already in. Can we
> proceed with it?
12 matches
Mail list logo
