[vtk-developers] Python Wrapping fails in master build.
andrew.amaclean at gmail.com
Wed Sep 26 06:07:31 EDT 2018
Just to add to this, I'm using CMake 3.12.2, the latest release version of
nmake built by the latest release of VS2017. One machine is my new Dell
XPS-15 9570 4k laptop 32GB memory 1TB ssd
and, it's fast! I installed Kubuntu as a dual boot on it and builds there
are the fastest I've ever seen. The other machine is a desktop with the
same software also dual boot. So it's the latest software on both machines.
On Wed, 26 Sep 2018, 14:23 David Gobbi <david.gobbi at gmail.com> wrote:
> Hi Andras, it's good to hear that someone else has seen problems similar
> to what Andrew is seeing.
> On Tue, Sep 25, 2018 at 7:37 PM Andras Lasso <lasso at queensu.ca> wrote:
>> It is probably worth asking CMake developers about what could be a good
>> approach to address this.
> Brad, have there been any new discoveries about why compiler tests and
> custom-command outputs fail to open their output files on Windows as
> described in this cmake issue? (https://cmake.org/Bug/view.php?id=12957).
> This is something that Andrew is seeing on his machine, that I haven't been
> able to reproduce on my own machine yet.
> Retrying a file operation can have many non-trivial side effects so it
>> should be avoided. As far as I know, there is no such workaround anywhere
>> in CMake, so it should be possible to avoid it in vtkWrapPython, too.
> This isn't always true. On Linux when fread fails with errno=EINTR,
> retrying is the correct response, and there are a few places where this is
> done in the CMake code base. The errno=EINTR condition is very short
> lived. It would be nice if the failure on Windows was something similar
> (i.e. instantly retryable) but I suspect it isn't. I strongly suspect the
> failure is a sharing violation, for which the correct response is usually
> to write to a different file (which is not ideal).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vtk-developers