OK, got it to work in VS2013 x64 cross-compiling, seem like my -G flag was not register into the cmake command, du to a non printable character from utf-8 copy paste to ainsi (damn Windows console sometime). The reason why I end up with a solution and not the Makefiles as an output from the cmake.
On Fri, Jun 26, 2015 at 4:35 PM, Jérôme Godbout <jer...@bodycad.com> wrote: > VS2013 x64 Native Tools Command Prompt > > On Fri, Jun 26, 2015 at 4:34 PM, Samuel Gaist <samuel.ga...@edeltech.ch> > wrote: > >> Hi, >> >> There's no such limitation, you can build it in 64bit. >> >> Did you start your build from a amd64 or x86_amd64 cross-compiling >> console ? >> >> >> On 26 juin 2015, at 21:04, Jérôme Godbout <jer...@bodycad.com> wrote: >> >> > I'm trying to compile GammaRay, anybody manage to compile it in x64 >> under Windows? >> > >> > I manage to compile VTK and set the proper env (VTK_DIR) against Qt 5 >> x64. I couldn't compile Graphiz in x64 (complaining about missing header >> textspan.h, manually give it to him, still cannot compile it in x64, the >> solution doesn't work in VS2012). Even without Graphiz, the solution output >> by GammaRay cmake doesn't have any x64 into. Even if I add the >> configuration for x64, I still end up with many erros: >> > Error 19 error LNK1112: module machine type 'x64' conflicts with >> target machine type 'X86' >> ...\build\tests\manual\x64\Release\wk2application.obj 1 >> > >> > I guess we are only suppose to compile GammaRay in 32 bits. Can we >> compile it in x86 with Qt 5 x86 and run it to debug Qt 5 x64 after >> properly? We only have a 64 bits version of ours app, we drop 32 bits >> support last years. >> > >> > >> > >> > On Fri, Jun 26, 2015 at 9:33 AM, Jérôme Godbout <jer...@bodycad.com> >> wrote: >> > Hi, >> > thanks all for your inputs, there's a few thing I was not aware of. For >> the visualizer, I see little benefit in my use case in desktop, probably >> more useful for embedded platform project which I think still have a real >> world purpose. >> > >> > As for GammaRay, it's slow down our application too much, we are doing >> 3D CAD application with Qml (we have 3D scene render into texture and many >> many objects into our Qml Tree, since the 3D objects are part of it as >> children to our 3D viewport, yeah it's weird usage but make our application >> very flexible). We tested GammaRay around summer years 2014 if I remember >> correctly (2.1.0 I guess). It does the object inspection well, can edit, >> invoke and emit was not working so well at the time, maybe they fixed it by >> now. Singleton are not supported. But mainly, it make our application run >> like it's in debug which is way too slow to our liking. Not sure if their >> was any improvement on this, but for day to day work, it was not cutting it >> at the time. >> > >> > From the change log since my last eval (available here for those who >> are looking for it, should realy put a link on the main page to this): >> > https://github.com/KDAB/GammaRay/releases >> > • Support displaying of QQmlListProperty contents. >> > • Fix invoking non-slot methods with arguments. >> > • Expose signal/slot spy callback API to plug-ins. >> > • Support for manually emitting signals, and improved method >> display. >> > • Fix crash when target deletes a signal sender in a slot. >> > Seem like I should give it another spin. Our in house tool is doing >> this without much slow down and can even perform >> invoke/emit/inspect/edit/regex search on object based on ptr/name/id/type >> and clickable to navigate through childs/parent. Wish we could license it >> open source, but I doubt we could do that here :-( Seem like maybe >> GammaRay have evolved enough so we can ditch in-house implementation, will >> let the list known how it did go as soon as I can have time to test the >> latest release. >> > >> > I'm looking forward for that QtCreator items inspector, would love to >> see it spin off of QtCreator and becoming a component on it's own, that >> would help many people who are using other IDE. I was not aware of this >> one, thanks for the info. >> > >> > On a side note, I agree a Qml would need a TreeView, would remove our >> dependencies on QWidgets for us. >> > >> > >> > >> > >> > On Fri, Jun 26, 2015 at 6:33 AM, Rutledge Shawn < >> shawn.rutle...@theqtcompany.com> wrote: >> > >> > On 25 Jun 2015, at 21:41, Jérôme Godbout <jer...@bodycad.com> wrote: >> > >> > > There's GammaRay >> > > http://www.kdab.com/kdab-products/gammaray/ >> > > https://github.com/KDAB/GammaRay >> > > >> > > It's not 100% efficient, but better then nothing. We end up doing our >> own debugger command line to search and inspect object along a TreeView >> from QWidgets to see/edit properties, pointer value, invoke methods and >> emit signal. I would love to see one build for Qml build-in, we could stop >> maintain ours. >> > >> > https://codereview.qt-project.org/#/c/44322/ is a patch for qmlscene >> which I’ve been occasionally developing and using for a long time (2012 or >> so). Earlier versions looked at the object hierarchy (the QObject >> parent/child relationship), whereas now it looks at the top-level Item’s >> childItems(). Each way has its advantages… There is a QAIM model and a >> QTreeView to view the items and a few properties, and a “dump” button to >> get the rest. >> > >> > However it’s not desirable to have a dependency on widgets in a QML >> tool. (Although maybe having it in qmlscene wouldn’t be so bad, because we >> are trying to deprecate qmlscene anyway.) And it crashes sometimes, >> because the tree does not automatically remove objects when they are >> destroyed, so it can end up trying to get properties from dead objects. >> I’m sure that’s fixable if the desire continues to have such a tool. Maybe >> it could even be dynamically loaded by the qml tool, instead of being >> linked in. And I’d want it to be able to discover all of an application’s >> windows. And I’d like to have it show the scene graph nodes which each >> Item is responsible for, and the z stacking order. >> > >> > Ideally maybe we should have a TreeView which can directly use any >> object hierarchy as the model, without needing a QAIM. But of course such >> a tree would have to avoid inspecting itself. >> > >> > Maybe it’s not worth doing, now that GammaRay is working well enough? >> What do you not like about GammaRay at this point? >> > >> > >> > >> > _______________________________________________ >> > Interest mailing list >> > Interest@qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/interest >> >> >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
