[Paraview-developers] Goodbye windows, Hello Mac
Biddiscombe, John A.
biddisco at cscs.ch
Mon Oct 28 18:14:43 EDT 2013
Thanks for all the info gathered so far, both on and off list. I'm very impressed with anyone developing paraview using vim+gdb. QtCreator is getting good press, I'm not hearing many votes for xcode. NB. I will be switching mostly to clan rather than gcc wherever possible as the BG/Q I'm working on has good clan support. Thanks for reminding me of lldb.
RE;Constant rebuilds. I upgraded my VS2010 to 2012 around the same time I moved to pv3.98 and possibly upgraded cmake, I posted this question
http://www.paraview.org/pipermail/paraview/2012-November/026789.html
looks like nov 2012. I spent some time trying to work out what the problem was and experimented with /MP options and other things, but never quite nailed down what the problem was. Providing I'm working on plugins, the problem is not so bad, but recently changing one header file in pqComponents or similar would trigger massive rebuilds that are just too painful. As a general rule, changing one file in a project (=target not the whole solution) causes the whole target to rebuild. Changing anything qt related seems worse as moc files get regenerated much too frequently and the whole lot rebuilds. This cascades to dependent projects. Client/server wrapper stuff rebuilds much too frequently (touching cmakelists files can trigger it), python wrapping rebuilds much too frequently (this started when the wrappers were updated with some hierarchy.txt files getting generated). I was never able to pin down exactly what the problem was with any of the rebuilds, so I just gave up and developed workflows where I avoided changing anything where possible (don't switch git branches if they affect a cmakelists file!) - and use remote desktop to my workstation with a 12 core processor and builds are less painful. (I use the /MP option which does trigger more builds, but they happen so much faster that it outweighs the disadvantages).
My suspicion is that there is something wrong with visual studio, but nobody else is reporting it for other projects (and those that do fix it by removing non existing rules/files from their projects). Projects not generated with cmake don't seem to suffer - and my other Qt projects which don't use paraview don't seem nearly so bad - but they are small - you only really notice it on my 4 year old laptop and a massive project like PV. - it is hard to be sure where the fault lies. A good person would have spent more time trying to fix it, but I'm a bad person and selfish and switching to a mac seems easier - even if I'm not cool ... or a hipster &etc &etc :)
JB
Dave D. I've only just ordered the new machine and it hasn't yet arrived, so any change in recent behaviour is probably caused a planetary conjunction, or some constellation being in ascendance - nothing to worry about I'm sure.
>>
> I would be interested in hearing more information about the constant
> rebuilds that occur under VisualStudio. Are these targets that are
> constantly out of date?
> Do we have a bug submitted to the CMake project about this issue?
I haven't observed this. I guess that the problems I experienced where because of the strategy that MSVC used for parallelization. It always seems to build serially when it hits the PV Qt code, dragging the build out. I assume it's because MSVC is using a build thread per target, when it hits PV Qt targets there are a bunch of other PV targets that have to wait for it and it just gets stuck in a serial build. I breifly experimented with the /MP flag but it made things worse. Python wraping is slower than I'd expect as well. I blame MSVC for these issues, which seems reasonable since ninja works so well without any tuning. I'm using vs express 2010.
<<
More information about the Paraview-developers
mailing list