From bob.obara at kitware.com Sun May 3 15:57:25 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Sun, 3 May 2015 15:57:25 -0400 Subject: [Smtk-developers] qtModelOperationWidget Message-ID: Hi Folks, I have a conceptual question concerning how Views work w/r operators: Who creates and maintains the attribute system which contains all of the operator attribute specifications? qtModelOperationWidget (through setCurrentOperation) - modifies the root view by adding an instance view for the operator - does this ever get deleted? It looks like the root view is never processed by the qtUIManager - only the instanced is processed - Am I correct? If I am, why? Now that we can add new qtViewWdigets to the UI Manager - do we need to create a operator specific qt view class? Thanks! Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Sun May 3 16:54:35 2015 From: david.thompson at kitware.com (David Thompson) Date: Sun, 3 May 2015 16:54:35 -0400 Subject: [Smtk-developers] qtModelOperationWidget In-Reply-To: References: Message-ID: Hi Bob, Each model::Session instance owns an attribute system holding the Definition instances for all the operations it supports. The operator definitions are all XML files that have been encoded as C strings by each operator and are collected in static variables by each Session subclass as the operators register themselves with the Session. Yumin will have to answer the question about qtModelOperationWidget... I am blissfully ignorant of that bit. :-) David > On May 3, 2015, at 15:57, Robert Michael O'Bara wrote: > > Hi Folks, > > I have a conceptual question concerning how Views work w/r operators: > > Who creates and maintains the attribute system which contains all of the operator attribute specifications? > > qtModelOperationWidget (through setCurrentOperation) - modifies the root view by adding an instance view for the operator - does this ever get deleted? > > It looks like the root view is never processed by the qtUIManager - only the instanced is processed - Am I correct? If I am, why? > Now that we can add new qtViewWdigets to the UI Manager - do we need to create a operator specific qt view class? > > > Thanks! > > Bob > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > > > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Sun May 3 18:27:42 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Sun, 3 May 2015 17:27:42 -0500 Subject: [Smtk-developers] qtModelOperationWidget In-Reply-To: References: Message-ID: Thanks David, Sent from my iPhone > On May 3, 2015, at 3:54 PM, David Thompson wrote: > > Hi Bob, > > Each model::Session instance owns an attribute system holding the Definition instances for all the operations it supports. The operator definitions are all XML files that have been encoded as C strings by each operator and are collected in static variables by each Session subclass as the operators register themselves with the Session. > > Yumin will have to answer the question about qtModelOperationWidget... I am blissfully ignorant of that bit. :-) > > David > > > >> On May 3, 2015, at 15:57, Robert Michael O'Bara wrote: >> >> Hi Folks, >> >> I have a conceptual question concerning how Views work w/r operators: >> >> Who creates and maintains the attribute system which contains all of the operator attribute specifications? >> >> qtModelOperationWidget (through setCurrentOperation) - modifies the root view by adding an instance view for the operator - does this ever get deleted? >> >> It looks like the root view is never processed by the qtUIManager - only the instanced is processed - Am I correct? If I am, why? >> Now that we can add new qtViewWdigets to the UI Manager - do we need to create a operator specific qt view class? >> >> >> Thanks! >> >> Bob >> >> Robert M. O'Bara, MEng. >> Assistant Director of Scientific Computing >> >> Kitware Inc. >> 28 Corporate Drive >> Suite 101 >> Clifton Park, NY 12065 >> >> Phone: (518) 881- 4931 >> >> >> >> >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.yuan at kitware.com Mon May 4 09:02:18 2015 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Mon, 4 May 2015 09:02:18 -0400 Subject: [Smtk-developers] qtModelOperationWidget In-Reply-To: References: Message-ID: Hi Bob, On Sun, May 3, 2015 at 3:57 PM, Robert Michael O'Bara wrote: > Hi Folks, > > I have a conceptual question concerning how Views work w/r operators: > > Who creates and maintains the attribute system which contains all of the > operator attribute specifications? > > qtModelOperationWidget (through setCurrentOperation) - modifies the root > view by adding an instance view for the operator - does this ever get > deleted? > > The qtModelOperationWidget holds references of the qtInstancedView for operators once they are requested, and they will be deleted once the qtModelOperationWidget is removed from the system. > It looks like the root view is never processed by the qtUIManager - only > the instanced is processed - Am I correct? If I am, why? > This is another typical use of the "view" system before. We have a simple template, and all we need is a qtInstancedView to present the UI for the template, and we don't really need anything from the root view, but the way it was set up, we have to use the root view to get the UI for instanced view. > Now that we can add new qtViewWdigets to the UI Manager - do we need to > create a operator specific qt view class? > I would think not. To me this is a very simple use case for the new view system, and this is also how we generate the meshing panel in cmbV4. I am not sure how other projects are using the view system, but I think this is a common case. Basically, we have a template, and we want to use the qtInstancedView for it. Yumin > > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Mon May 4 11:45:18 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 4 May 2015 10:45:18 -0500 Subject: [Smtk-developers] New View Mechanism Branch Message-ID: <195D23CB-A8D9-4816-BBE8-4A23F6F228B1@kitware.com> Hi Yumin, On my Github SMTK repo I?ve pushed my current version of the new Views mechanism and in my SMTK Testing Data repo I have a added a proposed version 2 CTB template file. I?ve temporally disabled loading Views in version 1 files but will get that working shortly. The attribute previewer test that John created seems to work with my changes though it crashes when dealing with anything that require model association information - for example creating a material causes the program to crash but the original also crashed. Let me know what you think :) Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Mon May 4 23:41:40 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 4 May 2015 22:41:40 -0500 Subject: [Smtk-developers] Added V1 File Processing Message-ID: Hi Yumin, I added the ability to read Version 1 Attribute files w/r to the new View mechanism. I?ve pushed it to my gitHub branch. Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Mon May 4 23:50:05 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 4 May 2015 22:50:05 -0500 Subject: [Smtk-developers] Bug: Adding things to a group clears its color Message-ID: Hi Yumin, Adding anything to a group (either domain or boundary will cause the group to loose its assigned color. Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.yuan at kitware.com Tue May 5 08:42:28 2015 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Tue, 5 May 2015 08:42:28 -0400 Subject: [Smtk-developers] Added V1 File Processing In-Reply-To: References: Message-ID: Great, I will check it out, and also I will take a look at the crash of the attribute previewer test when creating material attributes. Yumin On Mon, May 4, 2015 at 11:41 PM, Robert Michael O'Bara < bob.obara at kitware.com> wrote: > Hi Yumin, > > I added the ability to read Version 1 Attribute files w/r to the new View > mechanism. I?ve pushed it to my gitHub branch. > > > Bob > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.yuan at kitware.com Fri May 8 13:16:43 2015 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Fri, 8 May 2015 13:16:43 -0400 Subject: [Smtk-developers] Added V1 File Processing In-Reply-To: References: Message-ID: Hi Bob, I looked over your branch briefly, and they look good to me, but I do have one suggestion You may want to check if there is a view with the same title already in the System, because a developer could unknowingly replace existing views. void System::addView(smtk::common::ViewPtr v) { this->m_views[v->title()] = v; } Yumin On Tue, May 5, 2015 at 8:42 AM, Yumin Yuan wrote: > Great, I will check it out, and also I will take a look at the crash of the > attribute previewer test when creating material attributes. > > Yumin > > On Mon, May 4, 2015 at 11:41 PM, Robert Michael O'Bara < > bob.obara at kitware.com> wrote: > >> Hi Yumin, >> >> I added the ability to read Version 1 Attribute files w/r to the new View >> mechanism. I?ve pushed it to my gitHub branch. >> >> >> Bob >> >> Robert M. O'Bara, MEng. >> Assistant Director of Scientific Computing >> >> Kitware Inc. >> 28 Corporate Drive >> Suite 101 >> Clifton Park, NY 12065 >> >> Phone: (518) 881- 4931 >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Sat May 9 00:07:09 2015 From: david.thompson at kitware.com (David Thompson) Date: Sat, 9 May 2015 00:07:09 -0400 Subject: [Smtk-developers] Large merge Message-ID: <5A586E0E-CC99-425F-8ADF-2195264E940F@kitware.com> Hi all, I've merged a branch to SMTK that adds new functionality to the base Session class (a new way to transcribe) and additions to the discrete Session that take advantage of it. The discrete Session now properly transcribes use records as well as shell+loop uses. This is a significant change, so please let me know if you have problems. Yumin, if you haven't pushed changes to master for the discrete grow and split operators, please be careful about updating since we have both made changes to the discrete Session. If you push your branch somewhere, I will be happy to get it working with the changes I've just merged. Besides the changes to Session, this branch adds some methods that allow us to write Python-based image tests using the vtkModelMultiBlockSource. I hope to add some tests shortly that take advantage of this to provide better coverage of the CGM and discrete kernel operators. David From yumin.yuan at kitware.com Sat May 9 09:12:53 2015 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Sat, 9 May 2015 09:12:53 -0400 Subject: [Smtk-developers] Large merge In-Reply-To: <5A586E0E-CC99-425F-8ADF-2195264E940F@kitware.com> References: <5A586E0E-CC99-425F-8ADF-2195264E940F@kitware.com> Message-ID: Hi Dave, On Sat, May 9, 2015 at 12:07 AM, David Thompson wrote: > Hi all, > > I've merged a branch to SMTK that adds new functionality to the base > Session class (a new way to transcribe) and additions to the discrete > Session that take advantage of it. The discrete Session now properly > transcribes use records as well as shell+loop uses. This is a significant > change, so please let me know if you have problems. > > This sounds great. > Yumin, if you haven't pushed changes to master for the discrete grow and > split operators, please be careful about updating since we have both made > changes to the discrete Session. If you push your branch somewhere, I will > be happy to get it working with the changes I've just merged. > > I have a branch "discrete_split_edge" on my fork of smtk ( https://github.com/yumin/SMTK.git). The new EdgeOperator is working now for edge split and merge, and the tree view is updating properly with the new and deleted edge or vertex. However there seems to be a bug in updating the visibility property of the entities, and I am looking into that right now. Thanks, Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed May 13 14:36:36 2015 From: david.thompson at kitware.com (David Thompson) Date: Wed, 13 May 2015 14:36:36 -0400 Subject: [Smtk-developers] Testing grow and split Message-ID: Hi Yumin (et al.), FYI, I've pushed a new CMB discrete model to the SMTKTestData repo named cmb/pmdc.cmb. It is a CMB version of the pmdc.poly file that comes with TetGen. It has over 500 model faces, many of which have a small dihedral angle because they approximate cylindrical surfaces and would be great for testing the grow operator. Also FYI, I've added SetEntityProperty to the simple Python API and used it to color the pmdc model faces by their group membership. See the discrete and exodus ReadFile tests for an example of its usage as well as how to create an image-based Python test. I would really like to see tests like these for all the operators and would be happy to help. David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pmdc.png Type: image/png Size: 8199 bytes Desc: not available URL: From yumin.yuan at kitware.com Thu May 14 12:57:18 2015 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Thu, 14 May 2015 12:57:18 -0400 Subject: [Smtk-developers] Testing grow and split In-Reply-To: References: Message-ID: Thanks, Dave. This dataset looks great. I will start working on adding more tests in smtk (and cmb) once I finish the pressing tasks on hand. Thanks, Yumin On Wed, May 13, 2015 at 2:36 PM, David Thompson wrote: > Hi Yumin (et al.), > > FYI, I've pushed a new CMB discrete model to the SMTKTestData repo > named cmb/pmdc.cmb. It is a CMB version of the pmdc.poly file that comes > with TetGen. It has over 500 model faces, many of which have a small > dihedral angle because they approximate cylindrical surfaces and would be > great for testing the grow operator. > > Also FYI, I've added SetEntityProperty to the simple Python API and used > it to color the pmdc model faces by their group membership. See the > discrete and exodus ReadFile tests for an example of its usage as well as > how to create an image-based Python test. I would really like to see tests > like these for all the operators and would be happy to help. > > David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pmdc.png Type: image/png Size: 8199 bytes Desc: not available URL: From david.thompson at kitware.com Fri May 15 16:26:43 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 15 May 2015 16:26:43 -0400 Subject: [Smtk-developers] Heads up Message-ID: <3645FEEB-FFA3-4E07-B76C-1F0D53DA39B0@kitware.com> Hi all, I've just merged a large batch of changes to the release-v1 branch of SMTK. They require a new version of ParaView to compile. Yumin just pushed changes to the CMB superbuild in support of this (see https://gitlab.kitware.com/cmb/cmb-superbuild/merge_requests/30 ). David From david.thompson at kitware.com Thu May 21 19:55:21 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 21 May 2015 19:55:21 -0400 Subject: [Smtk-developers] SMTK operators in the UI Message-ID: Hi all, Yumin and I just had a chat about how to present a list of available bathymetry data to users in the operator panel. I'm sending this to summarize/record what we talked about (plus some related thoughts from talks with Rob about the mesh operator) and get feedback, if you have any, about custom user interfaces for operators. The client-server separation means that when an operator (such as "apply bathymetry") runs on the server, any modifications it makes to its definition (such as adding to the enumeration of bathymetry files currently loaded) are not available on the client. The way the attribute reader works (skipping pre-existing definitions) means that transmitting changes from the server would not work without manually parsing the XML and making matching changes on the client. However, some operators do clearly have persistent and/or volatile state associated with them so it seems that SMTK should help applications maintain and present it. Most of the solutions we came up with involve running some code on the client when an operator's result attribute is returned (in order to modify the attribute or the view). What's unclear to me is the best way to tie that code to the operator: Operators are defined in libraries that must not have UI dependencies. So, any custom UI code must clearly be in a separate library. Multiple UIs (e.g., desktop Qt, web browser, mobile app) may each have a different custom UI for the same operator (or only some UIs may be custom for some operators). The same custom UI may be suitable for multiple operators of the same name (i.e., when multiple sessions provide the same operator with identical semantics on the client). Thus there need not be a 1:1 mapping between session plugins and custom-operator-UI plugins. It seems that operators should not include markup specific to the view directly; multiple versions of the view (one for each platform's UI or for each application) may exist and could each mark up the same operator differently -- the same way many CSS files can mark up the same HTML to customize appearance. It also seems that there should be an optional but strongly-enforced-when-present connection between the matching attribute systems on the client and server so that custom UIs are not applied to operators from sessions of different types. Is the string specifying the "actual" session type enough? (Note that SMTK does not robustly provide the actual session type to forwarding sessions, but perhaps it should.) Since a custom UI may be optional, it is up to the application to enforce consistent loading of matching plugins on the server and client. For ModelBuilder, the smtkXXXSessionPlugin targets can specify that a matching ParaView-client-side plugin must also be loaded as needed. However, it is unclear what class would accept per-operator UI registration; what would invoke registered code on the UI side; and how the proper UI code would be identified given an operator and its session. What we can say is that the lifecycle of the UI involves: 1. Creating the custom UI elements. This could be done (1) as soon as an Operator instance (and its specification attribute) is created or (2) when a view of the operator is requested (but before anything is known about the view so that the UI has an opportunity to modify the view). The latter makes the most sense because otherwise the custom UI will not have a parent widget or context in which to place itself. 2. Signaling the UI when there is an event related to the operator. SMTK provides callbacks when an operator is about to be applied and when it has just completed. It might be nice for a base UI customization class to automatically register for these callbacks. 3. Interacting with the possibly-remote Operator instance. Currently the Operator class only provides ableToOperate() and operate() methods. However some operators may provide feedback while the specification is in progress (e.g., the grow operator can indicate the faces that will result). Custom UIs will frequently wish to take advantage of this; how can SMTK accommodate more generic communication between the UI and operator? 4. Destroying the UI. This could happen in tandem with the Operator instance and its attribute; or when its containing view is destroyed. David From bob.obara at kitware.com Thu May 21 23:51:39 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Thu, 21 May 2015 23:51:39 -0400 Subject: [Smtk-developers] SMTK operators in the UI In-Reply-To: References: Message-ID: <2FA77FC0-6106-43E7-B201-98C6A8519A5F@kitware.com> Hi Guys, First I want to say this really does a good job at describing some of the issues facing SMTK with future expansion and will have to be discussed more thoroughly (current funding is a bit tight right now in terms of solving this in general). In terms of the Bathymetry issues - I think there might be a short term solution that could implemented relatively quickly. Instead of thinking the user is selecting the Bathymetry using a discrete based item (with enums representing already loaded files), what if we represent it as a File Item instead and have the ability for the file item widget to remember the files that the user has already attempted to load? One small drawback with this is that files that failed to load would still be listed but that might not be a bad trade-off. An alternative would be to add an option in the View description to indicate that in addition to a file item, an attribute also includes a vector of strings that represent ?quick? selectable files. For example consider a definition of Bathymetry consisting of a file item definition called fname and another string item (which is not displayed directly) called already loaded files. Initially the string item is empty (though in the future this could be pre-populated based on an user preference). Each time a file is successfully loaded the server would add its name to the ?already? loaded item which would then get passed back to the client on request. In this case the definition does not need to be touched. Does this make sense? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On May 21, 2015, at 7:55 PM, David Thompson wrote: > > Hi all, > > Yumin and I just had a chat about how to present a list of available bathymetry data to users in the operator panel. I'm sending this to summarize/record what we talked about (plus some related thoughts from talks with Rob about the mesh operator) and get feedback, if you have any, about custom user interfaces for operators. > > The client-server separation means that when an operator (such as "apply bathymetry") runs on the server, any modifications it makes to its definition (such as adding to the enumeration of bathymetry files currently loaded) are not available on the client. The way the attribute reader works (skipping pre-existing definitions) means that transmitting changes from the server would not work without manually parsing the XML and making matching changes on the client. However, some operators do clearly have persistent and/or volatile state associated with them so it seems that SMTK should help applications maintain and present it. > > Most of the solutions we came up with involve running some code on the client when an operator's result attribute is returned (in order to modify the attribute or the view). What's unclear to me is the best way to tie that code to the operator: > > Operators are defined in libraries that must not have UI dependencies. So, any custom UI code must clearly be in a separate library. Multiple UIs (e.g., desktop Qt, web browser, mobile app) may each have a different custom UI for the same operator (or only some UIs may be custom for some operators). The same custom UI may be suitable for multiple operators of the same name (i.e., when multiple sessions provide the same operator with identical semantics on the client). Thus there need not be a 1:1 mapping between session plugins and custom-operator-UI plugins. > > It seems that operators should not include markup specific to the view directly; multiple versions of the view (one for each platform's UI or for each application) may exist and could each mark up the same operator differently -- the same way many CSS files can mark up the same HTML to customize appearance. > > It also seems that there should be an optional but strongly-enforced-when-present connection between the matching attribute systems on the client and server so that custom UIs are not applied to operators from sessions of different types. Is the string specifying the "actual" session type enough? (Note that SMTK does not robustly provide the actual session type to forwarding sessions, but perhaps it should.) > > Since a custom UI may be optional, it is up to the application to enforce consistent loading of matching plugins on the server and client. For ModelBuilder, the smtkXXXSessionPlugin targets can specify that a matching ParaView-client-side plugin must also be loaded as needed. However, it is unclear what class would accept per-operator UI registration; what would invoke registered code on the UI side; and how the proper UI code would be identified given an operator and its session. What we can say is that the lifecycle of the UI involves: > > 1. Creating the custom UI elements. This could be done (1) as soon as an Operator instance (and its specification attribute) is created or (2) when a view of the operator is requested (but before anything is known about the view so that the UI has an opportunity to modify the view). The latter makes the most sense because otherwise the custom UI will not have a parent widget or context in which to place itself. > > 2. Signaling the UI when there is an event related to the operator. SMTK provides callbacks when an operator is about to be applied and when it has just completed. It might be nice for a base UI customization class to automatically register for these callbacks. > > 3. Interacting with the possibly-remote Operator instance. Currently the Operator class only provides ableToOperate() and operate() methods. However some operators may provide feedback while the specification is in progress (e.g., the grow operator can indicate the faces that will result). Custom UIs will frequently wish to take advantage of this; how can SMTK accommodate more generic communication between the UI and operator? > > 4. Destroying the UI. This could happen in tandem with the Operator instance and its attribute; or when its containing view is destroyed. > > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri May 22 00:20:22 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 22 May 2015 00:20:22 -0400 Subject: [Smtk-developers] SMTK operators in the UI In-Reply-To: <2FA77FC0-6106-43E7-B201-98C6A8519A5F@kitware.com> References: <2FA77FC0-6106-43E7-B201-98C6A8519A5F@kitware.com> Message-ID: I certainly think that a custom widget on the client side (either the custom view entry or the file chooser with recent files listed) would be a lot easier to implement in the short term. David > On May 21, 2015, at 23:51, Robert Michael O'Bara wrote: > > Hi Guys, > > First I want to say this really does a good job at describing some of the issues facing SMTK with future expansion and will have to be discussed more thoroughly (current funding is a bit tight right now in terms of solving this in general). > > In terms of the Bathymetry issues - I think there might be a short term solution that could implemented relatively quickly. Instead of thinking the user is selecting the Bathymetry using a discrete based item (with enums representing already loaded files), what if we represent it as a File Item instead and have the ability for the file item widget to remember the files that the user has already attempted to load? One small drawback with this is that files that failed to load would still be listed but that might not be a bad trade-off. > > An alternative would be to add an option in the View description to indicate that in addition to a file item, an attribute also includes a vector of strings that represent ?quick? selectable files. For example consider a definition of Bathymetry consisting of a file item definition called fname and another string item (which is not displayed directly) called already loaded files. Initially the string item is empty (though in the future this could be pre-populated based on an user preference). Each time a file is successfully loaded the server would add its name to the ?already? loaded item which would then get passed back to the client on request. In this case the definition does not need to be touched. > > Does this make sense? > > Bob > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > > > > >> On May 21, 2015, at 7:55 PM, David Thompson wrote: >> >> Hi all, >> >> Yumin and I just had a chat about how to present a list of available bathymetry data to users in the operator panel. I'm sending this to summarize/record what we talked about (plus some related thoughts from talks with Rob about the mesh operator) and get feedback, if you have any, about custom user interfaces for operators. >> >> The client-server separation means that when an operator (such as "apply bathymetry") runs on the server, any modifications it makes to its definition (such as adding to the enumeration of bathymetry files currently loaded) are not available on the client. The way the attribute reader works (skipping pre-existing definitions) means that transmitting changes from the server would not work without manually parsing the XML and making matching changes on the client. However, some operators do clearly have persistent and/or volatile state associated with them so it seems that SMTK should help applications maintain and present it. >> >> Most of the solutions we came up with involve running some code on the client when an operator's result attribute is returned (in order to modify the attribute or the view). What's unclear to me is the best way to tie that code to the operator: >> >> Operators are defined in libraries that must not have UI dependencies. So, any custom UI code must clearly be in a separate library. Multiple UIs (e.g., desktop Qt, web browser, mobile app) may each have a different custom UI for the same operator (or only some UIs may be custom for some operators). The same custom UI may be suitable for multiple operators of the same name (i.e., when multiple sessions provide the same operator with identical semantics on the client). Thus there need not be a 1:1 mapping between session plugins and custom-operator-UI plugins. >> >> It seems that operators should not include markup specific to the view directly; multiple versions of the view (one for each platform's UI or for each application) may exist and could each mark up the same operator differently -- the same way many CSS files can mark up the same HTML to customize appearance. >> >> It also seems that there should be an optional but strongly-enforced-when-present connection between the matching attribute systems on the client and server so that custom UIs are not applied to operators from sessions of different types. Is the string specifying the "actual" session type enough? (Note that SMTK does not robustly provide the actual session type to forwarding sessions, but perhaps it should.) >> >> Since a custom UI may be optional, it is up to the application to enforce consistent loading of matching plugins on the server and client. For ModelBuilder, the smtkXXXSessionPlugin targets can specify that a matching ParaView-client-side plugin must also be loaded as needed. However, it is unclear what class would accept per-operator UI registration; what would invoke registered code on the UI side; and how the proper UI code would be identified given an operator and its session. What we can say is that the lifecycle of the UI involves: >> >> 1. Creating the custom UI elements. This could be done (1) as soon as an Operator instance (and its specification attribute) is created or (2) when a view of the operator is requested (but before anything is known about the view so that the UI has an opportunity to modify the view). The latter makes the most sense because otherwise the custom UI will not have a parent widget or context in which to place itself. >> >> 2. Signaling the UI when there is an event related to the operator. SMTK provides callbacks when an operator is about to be applied and when it has just completed. It might be nice for a base UI customization class to automatically register for these callbacks. >> >> 3. Interacting with the possibly-remote Operator instance. Currently the Operator class only provides ableToOperate() and operate() methods. However some operators may provide feedback while the specification is in progress (e.g., the grow operator can indicate the faces that will result). Custom UIs will frequently wish to take advantage of this; how can SMTK accommodate more generic communication between the UI and operator? >> >> 4. Destroying the UI. This could happen in tandem with the Operator instance and its attribute; or when its containing view is destroyed. >> >> David >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Fri May 22 07:42:12 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Fri, 22 May 2015 07:42:12 -0400 Subject: [Smtk-developers] SMTK operators in the UI In-Reply-To: References: <2FA77FC0-6106-43E7-B201-98C6A8519A5F@kitware.com> Message-ID: Actually what I'm proposing is not a custom widget but better Gui options when dealing with file items in smtk. For example in instanced views we could add a component style option that states the name of the item that represents the cache of file names. I can show an example of this later today. I'm running out the door for a car service this morning. Bob Sent from my iPad > On May 22, 2015, at 12:20 AM, David Thompson wrote: > > I certainly think that a custom widget on the client side (either the custom view entry or the file chooser with recent files listed) would be a lot easier to implement in the short term. > > David > > > >> On May 21, 2015, at 23:51, Robert Michael O'Bara wrote: >> >> Hi Guys, >> >> First I want to say this really does a good job at describing some of the issues facing SMTK with future expansion and will have to be discussed more thoroughly (current funding is a bit tight right now in terms of solving this in general). >> >> In terms of the Bathymetry issues - I think there might be a short term solution that could implemented relatively quickly. Instead of thinking the user is selecting the Bathymetry using a discrete based item (with enums representing already loaded files), what if we represent it as a File Item instead and have the ability for the file item widget to remember the files that the user has already attempted to load? One small drawback with this is that files that failed to load would still be listed but that might not be a bad trade-off. >> >> An alternative would be to add an option in the View description to indicate that in addition to a file item, an attribute also includes a vector of strings that represent ?quick? selectable files. For example consider a definition of Bathymetry consisting of a file item definition called fname and another string item (which is not displayed directly) called already loaded files. Initially the string item is empty (though in the future this could be pre-populated based on an user preference). Each time a file is successfully loaded the server would add its name to the ?already? loaded item which would then get passed back to the client on request. In this case the definition does not need to be touched. >> >> Does this make sense? >> >> Bob >> >> Robert M. O'Bara, MEng. >> Assistant Director of Scientific Computing >> >> Kitware Inc. >> 28 Corporate Drive >> Suite 101 >> Clifton Park, NY 12065 >> >> Phone: (518) 881- 4931 >> >> >> >> >>> On May 21, 2015, at 7:55 PM, David Thompson wrote: >>> >>> Hi all, >>> >>> Yumin and I just had a chat about how to present a list of available bathymetry data to users in the operator panel. I'm sending this to summarize/record what we talked about (plus some related thoughts from talks with Rob about the mesh operator) and get feedback, if you have any, about custom user interfaces for operators. >>> >>> The client-server separation means that when an operator (such as "apply bathymetry") runs on the server, any modifications it makes to its definition (such as adding to the enumeration of bathymetry files currently loaded) are not available on the client. The way the attribute reader works (skipping pre-existing definitions) means that transmitting changes from the server would not work without manually parsing the XML and making matching changes on the client. However, some operators do clearly have persistent and/or volatile state associated with them so it seems that SMTK should help applications maintain and present it. >>> >>> Most of the solutions we came up with involve running some code on the client when an operator's result attribute is returned (in order to modify the attribute or the view). What's unclear to me is the best way to tie that code to the operator: >>> >>> Operators are defined in libraries that must not have UI dependencies. So, any custom UI code must clearly be in a separate library. Multiple UIs (e.g., desktop Qt, web browser, mobile app) may each have a different custom UI for the same operator (or only some UIs may be custom for some operators). The same custom UI may be suitable for multiple operators of the same name (i.e., when multiple sessions provide the same operator with identical semantics on the client). Thus there need not be a 1:1 mapping between session plugins and custom-operator-UI plugins. >>> >>> It seems that operators should not include markup specific to the view directly; multiple versions of the view (one for each platform's UI or for each application) may exist and could each mark up the same operator differently -- the same way many CSS files can mark up the same HTML to customize appearance. >>> >>> It also seems that there should be an optional but strongly-enforced-when-present connection between the matching attribute systems on the client and server so that custom UIs are not applied to operators from sessions of different types. Is the string specifying the "actual" session type enough? (Note that SMTK does not robustly provide the actual session type to forwarding sessions, but perhaps it should.) >>> >>> Since a custom UI may be optional, it is up to the application to enforce consistent loading of matching plugins on the server and client. For ModelBuilder, the smtkXXXSessionPlugin targets can specify that a matching ParaView-client-side plugin must also be loaded as needed. However, it is unclear what class would accept per-operator UI registration; what would invoke registered code on the UI side; and how the proper UI code would be identified given an operator and its session. What we can say is that the lifecycle of the UI involves: >>> >>> 1. Creating the custom UI elements. This could be done (1) as soon as an Operator instance (and its specification attribute) is created or (2) when a view of the operator is requested (but before anything is known about the view so that the UI has an opportunity to modify the view). The latter makes the most sense because otherwise the custom UI will not have a parent widget or context in which to place itself. >>> >>> 2. Signaling the UI when there is an event related to the operator. SMTK provides callbacks when an operator is about to be applied and when it has just completed. It might be nice for a base UI customization class to automatically register for these callbacks. >>> >>> 3. Interacting with the possibly-remote Operator instance. Currently the Operator class only provides ableToOperate() and operate() methods. However some operators may provide feedback while the specification is in progress (e.g., the grow operator can indicate the faces that will result). Custom UIs will frequently wish to take advantage of this; how can SMTK accommodate more generic communication between the UI and operator? >>> >>> 4. Destroying the UI. This could happen in tandem with the Operator instance and its attribute; or when its containing view is destroyed. >>> >>> David >>> _______________________________________________ >>> Smtk-developers mailing list >>> Smtk-developers at smtk.org >>> http://public.kitware.com/mailman/listinfo/smtk-developers >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.yuan at kitware.com Fri May 22 09:30:04 2015 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Fri, 22 May 2015 09:30:04 -0400 Subject: [Smtk-developers] SMTK operators in the UI In-Reply-To: References: <2FA77FC0-6106-43E7-B201-98C6A8519A5F@kitware.com> Message-ID: Hi Dave, That's a great summary and lots of nice ideas. We should create an issue on github with you email. But I agree with Bob, a short term solution will be more desirable currently. Bob, On Fri, May 22, 2015 at 7:42 AM, Robert Michael O'Bara < bob.obara at kitware.com> wrote: > Actually what I'm proposing is not a custom widget but better Gui options > when dealing with file items in smtk. > For example in instanced views we could add a component style option that > states the name of the item that represents the cache of file names. I can > show an example of this later today. I'm running out the door for a car > service this morning. > > Here is what I am thinking that could work. In the XML template, we already have "ShouldExist" for FileItemDefinition, which is to tell the dialog to be an Open or Save dialog. We can add a vector of strings in FileItem class (call it "recentExistingList"), and if "ShoudExist" is true, recentExistingList will cache the files that has been set to the FileItem, also in this case for qtFileItem widget, we will use a combobox instead of the textbox on the UI to present the list. This way, we don't have to touch anything else, and I agree "showing the recent file list" is a better UI option anyway. Yumin > Sent from my iPad > > On May 22, 2015, at 12:20 AM, David Thompson > wrote: > > I certainly think that a custom widget on the client side (either the > custom view entry or the file chooser with recent files listed) would be a > lot easier to implement in the short term. > > David > > > > On May 21, 2015, at 23:51, Robert Michael O'Bara > wrote: > > Hi Guys, > > First I want to say this really does a good job at describing some of the > issues facing SMTK with future expansion and will have to be discussed more > thoroughly (current funding is a bit tight right now in terms of solving > this in general). > > In terms of the Bathymetry issues - I think there might be a short term > solution that could implemented relatively quickly. Instead of thinking > the user is selecting the Bathymetry using a discrete based item (with > enums representing already loaded files), what if we represent it as a File > Item instead and have the ability for the file item widget to remember the > files that the user has already attempted to load? One small drawback with > this is that files that failed to load would still be listed but that might > not be a bad trade-off. > > An alternative would be to add an option in the View description to > indicate that in addition to a file item, an attribute also includes a > vector of strings that represent ?quick? selectable files. For example > consider a definition of Bathymetry consisting of a file item definition > called fname and another string item (which is not displayed directly) > called already loaded files. Initially the string item is empty (though in > the future this could be pre-populated based on an user preference). Each > time a file is successfully loaded the server would add its name to the > ?already? loaded item which would then get passed back to the client on > request. In this case the definition does not need to be touched. > > Does this make sense? > > Bob > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > > > > > On May 21, 2015, at 7:55 PM, David Thompson > wrote: > > Hi all, > > Yumin and I just had a chat about how to present a list of available > bathymetry data to users in the operator panel. I'm sending this to > summarize/record what we talked about (plus some related thoughts from > talks with Rob about the mesh operator) and get feedback, if you have any, > about custom user interfaces for operators. > > The client-server separation means that when an operator (such as "apply > bathymetry") runs on the server, any modifications it makes to its > definition (such as adding to the enumeration of bathymetry files currently > loaded) are not available on the client. The way the attribute reader works > (skipping pre-existing definitions) means that transmitting changes from > the server would not work without manually parsing the XML and making > matching changes on the client. However, some operators do clearly have > persistent and/or volatile state associated with them so it seems that SMTK > should help applications maintain and present it. > > Most of the solutions we came up with involve running some code on the > client when an operator's result attribute is returned (in order to modify > the attribute or the view). What's unclear to me is the best way to tie > that code to the operator: > > Operators are defined in libraries that must not have UI dependencies. So, > any custom UI code must clearly be in a separate library. Multiple UIs > (e.g., desktop Qt, web browser, mobile app) may each have a different > custom UI for the same operator (or only some UIs may be custom for some > operators). The same custom UI may be suitable for multiple operators of > the same name (i.e., when multiple sessions provide the same operator with > identical semantics on the client). Thus there need not be a 1:1 mapping > between session plugins and custom-operator-UI plugins. > > It seems that operators should not include markup specific to the view > directly; multiple versions of the view (one for each platform's UI or for > each application) may exist and could each mark up the same operator > differently -- the same way many CSS files can mark up the same HTML to > customize appearance. > > It also seems that there should be an optional but > strongly-enforced-when-present connection between the matching attribute > systems on the client and server so that custom UIs are not applied to > operators from sessions of different types. Is the string specifying the > "actual" session type enough? (Note that SMTK does not robustly provide the > actual session type to forwarding sessions, but perhaps it should.) > > Since a custom UI may be optional, it is up to the application to enforce > consistent loading of matching plugins on the server and client. For > ModelBuilder, the smtkXXXSessionPlugin targets can specify that a matching > ParaView-client-side plugin must also be loaded as needed. However, it is > unclear what class would accept per-operator UI registration; what would > invoke registered code on the UI side; and how the proper UI code would be > identified given an operator and its session. What we can say is that the > lifecycle of the UI involves: > > 1. Creating the custom UI elements. This could be done (1) as soon as an > Operator instance (and its specification attribute) is created or (2) when > a view of the operator is requested (but before anything is known about the > view so that the UI has an opportunity to modify the view). The latter > makes the most sense because otherwise the custom UI will not have a parent > widget or context in which to place itself. > > 2. Signaling the UI when there is an event related to the operator. SMTK > provides callbacks when an operator is about to be applied and when it has > just completed. It might be nice for a base UI customization class to > automatically register for these callbacks. > > 3. Interacting with the possibly-remote Operator instance. Currently the > Operator class only provides ableToOperate() and operate() methods. However > some operators may provide feedback while the specification is in progress > (e.g., the grow operator can indicate the faces that will result). Custom > UIs will frequently wish to take advantage of this; how can SMTK > accommodate more generic communication between the UI and operator? > > 4. Destroying the UI. This could happen in tandem with the Operator > instance and its attribute; or when its containing view is destroyed. > > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers > > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Fri May 22 10:25:53 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Fri, 22 May 2015 10:25:53 -0400 Subject: [Smtk-developers] SMTK operators in the UI In-Reply-To: References: <2FA77FC0-6106-43E7-B201-98C6A8519A5F@kitware.com> Message-ID: <79F0433E-797B-4010-90E1-3613DEAF044C@kitware.com> I?ve updated the Views Google Doc to better explain what I was suggesting last night :) Your idea will work as well. Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On May 22, 2015, at 9:30 AM, Yumin Yuan wrote: > > Hi Dave, > > That's a great summary and lots of nice ideas. We should create an issue on github with you email. But I agree with Bob, a short term solution will be more desirable currently. > > Bob, > > On Fri, May 22, 2015 at 7:42 AM, Robert Michael O'Bara > wrote: > Actually what I'm proposing is not a custom widget but better Gui options when dealing with file items in smtk. > For example in instanced views we could add a component style option that states the name of the item that represents the cache of file names. I can show an example of this later today. I'm running out the door for a car service this morning. > > > Here is what I am thinking that could work. In the XML template, we already have "ShouldExist" for FileItemDefinition, which is to tell the dialog to be an Open or Save dialog. We can add a vector of strings in FileItem class (call it "recentExistingList"), and if "ShoudExist" is true, recentExistingList will cache the files that has been set to the FileItem, also in this case for qtFileItem widget, we will use a combobox instead of the textbox on the UI to present the list. This way, we don't have to touch anything else, and I agree "showing the recent file list" is a better UI option anyway. > > Yumin > > > > Sent from my iPad > > On May 22, 2015, at 12:20 AM, David Thompson > wrote: > >> I certainly think that a custom widget on the client side (either the custom view entry or the file chooser with recent files listed) would be a lot easier to implement in the short term. >> >> David >> >> >> >> On May 21, 2015, at 23:51, Robert Michael O'Bara > wrote: >> >>> Hi Guys, >>> >>> First I want to say this really does a good job at describing some of the issues facing SMTK with future expansion and will have to be discussed more thoroughly (current funding is a bit tight right now in terms of solving this in general). >>> >>> In terms of the Bathymetry issues - I think there might be a short term solution that could implemented relatively quickly. Instead of thinking the user is selecting the Bathymetry using a discrete based item (with enums representing already loaded files), what if we represent it as a File Item instead and have the ability for the file item widget to remember the files that the user has already attempted to load? One small drawback with this is that files that failed to load would still be listed but that might not be a bad trade-off. >>> >>> An alternative would be to add an option in the View description to indicate that in addition to a file item, an attribute also includes a vector of strings that represent ?quick? selectable files. For example consider a definition of Bathymetry consisting of a file item definition called fname and another string item (which is not displayed directly) called already loaded files. Initially the string item is empty (though in the future this could be pre-populated based on an user preference). Each time a file is successfully loaded the server would add its name to the ?already? loaded item which would then get passed back to the client on request. In this case the definition does not need to be touched. >>> >>> Does this make sense? >>> >>> Bob >>> >>> Robert M. O'Bara, MEng. >>> Assistant Director of Scientific Computing >>> >>> Kitware Inc. >>> 28 Corporate Drive >>> Suite 101 >>> Clifton Park, NY 12065 >>> >>> Phone: (518) 881- 4931 >>> >>> >>> >>> >>>> On May 21, 2015, at 7:55 PM, David Thompson > wrote: >>>> >>>> Hi all, >>>> >>>> Yumin and I just had a chat about how to present a list of available bathymetry data to users in the operator panel. I'm sending this to summarize/record what we talked about (plus some related thoughts from talks with Rob about the mesh operator) and get feedback, if you have any, about custom user interfaces for operators. >>>> >>>> The client-server separation means that when an operator (such as "apply bathymetry") runs on the server, any modifications it makes to its definition (such as adding to the enumeration of bathymetry files currently loaded) are not available on the client. The way the attribute reader works (skipping pre-existing definitions) means that transmitting changes from the server would not work without manually parsing the XML and making matching changes on the client. However, some operators do clearly have persistent and/or volatile state associated with them so it seems that SMTK should help applications maintain and present it. >>>> >>>> Most of the solutions we came up with involve running some code on the client when an operator's result attribute is returned (in order to modify the attribute or the view). What's unclear to me is the best way to tie that code to the operator: >>>> >>>> Operators are defined in libraries that must not have UI dependencies. So, any custom UI code must clearly be in a separate library. Multiple UIs (e.g., desktop Qt, web browser, mobile app) may each have a different custom UI for the same operator (or only some UIs may be custom for some operators). The same custom UI may be suitable for multiple operators of the same name (i.e., when multiple sessions provide the same operator with identical semantics on the client). Thus there need not be a 1:1 mapping between session plugins and custom-operator-UI plugins. >>>> >>>> It seems that operators should not include markup specific to the view directly; multiple versions of the view (one for each platform's UI or for each application) may exist and could each mark up the same operator differently -- the same way many CSS files can mark up the same HTML to customize appearance. >>>> >>>> It also seems that there should be an optional but strongly-enforced-when-present connection between the matching attribute systems on the client and server so that custom UIs are not applied to operators from sessions of different types. Is the string specifying the "actual" session type enough? (Note that SMTK does not robustly provide the actual session type to forwarding sessions, but perhaps it should.) >>>> >>>> Since a custom UI may be optional, it is up to the application to enforce consistent loading of matching plugins on the server and client. For ModelBuilder, the smtkXXXSessionPlugin targets can specify that a matching ParaView-client-side plugin must also be loaded as needed. However, it is unclear what class would accept per-operator UI registration; what would invoke registered code on the UI side; and how the proper UI code would be identified given an operator and its session. What we can say is that the lifecycle of the UI involves: >>>> >>>> 1. Creating the custom UI elements. This could be done (1) as soon as an Operator instance (and its specification attribute) is created or (2) when a view of the operator is requested (but before anything is known about the view so that the UI has an opportunity to modify the view). The latter makes the most sense because otherwise the custom UI will not have a parent widget or context in which to place itself. >>>> >>>> 2. Signaling the UI when there is an event related to the operator. SMTK provides callbacks when an operator is about to be applied and when it has just completed. It might be nice for a base UI customization class to automatically register for these callbacks. >>>> >>>> 3. Interacting with the possibly-remote Operator instance. Currently the Operator class only provides ableToOperate() and operate() methods. However some operators may provide feedback while the specification is in progress (e.g., the grow operator can indicate the faces that will result). Custom UIs will frequently wish to take advantage of this; how can SMTK accommodate more generic communication between the UI and operator? >>>> >>>> 4. Destroying the UI. This could happen in tandem with the Operator instance and its attribute; or when its containing view is destroyed. >>>> >>>> David >>>> _______________________________________________ >>>> Smtk-developers mailing list >>>> Smtk-developers at smtk.org >>>> http://public.kitware.com/mailman/listinfo/smtk-developers >>> > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri May 22 15:27:40 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 22 May 2015 15:27:40 -0400 Subject: [Smtk-developers] Builders beware: Header install location changing Message-ID: <1E7CBE8C-4C30-4F0B-B697-A6D276D5F5E9@kitware.com> Hi all, SMTK is about to start installing its headers into a different location (${PREFIX}/include/smtk/${SMTK_VERSION}/smtk instead of ${PREFIX}/include/smtk). CMB merge request #33 keeps CMB compiling but does require you to remove SMTK_INCLUDE_DIR from your CMB CMakeCache.txt file before rebuilding. It would also be wise to wipe the ${PREFIX}/include/smtk directory before updating+installing SMTK so that CMB doesn't find the old headers and break down the road. This change should make the build+test process less fragile since SMTK builds will no longer find installed headers and try to use those. I will merge the change to SMTK/master right now and wait until folks are ready to merge SMTK/master to SMTK/release-v1. The latter should happen coincidental with MR#33 merging on CMB. David From david.thompson at kitware.com Fri May 22 16:04:31 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 22 May 2015 16:04:31 -0400 Subject: [Smtk-developers] Builders beware: Header install location changing In-Reply-To: <1E7CBE8C-4C30-4F0B-B697-A6D276D5F5E9@kitware.com> References: <1E7CBE8C-4C30-4F0B-B697-A6D276D5F5E9@kitware.com> Message-ID: <0ECC2EF2-E6E6-4A47-B92E-F6C5BD0FE5A3@kitware.com> This has now been merged. I will tag SMTK's release-v1 branch as v1.0.0rc1. There should be a release-candidate 2 before the official SMTK v1.0 release. David > On May 22, 2015, at 3:27 PM, David Thompson wrote: > > Hi all, > > SMTK is about to start installing its headers into a different location (${PREFIX}/include/smtk/${SMTK_VERSION}/smtk instead of ${PREFIX}/include/smtk). CMB merge request #33 keeps CMB compiling but does require you to remove SMTK_INCLUDE_DIR from your CMB CMakeCache.txt file before rebuilding. It would also be wise to wipe the ${PREFIX}/include/smtk directory before updating+installing SMTK so that CMB doesn't find the old headers and break down the road. > > This change should make the build+test process less fragile since SMTK builds will no longer find installed headers and try to use those. I will merge the change to SMTK/master right now and wait until folks are ready to merge SMTK/master to SMTK/release-v1. The latter should happen coincidental with MR#33 merging on CMB. > > David From bob.obara at kitware.com Sun May 24 18:27:50 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Sun, 24 May 2015 18:27:50 -0400 Subject: [Smtk-developers] Problem with SMTK Master Message-ID: Hi All, I?ve updated all of the CMB files to reflect the correct license however while building CMB SuperBuild in develop mode SMTK is giving me an error: 41%] [ 41%] [ 41%] [ 41%] [ 41%] Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/ModelEntityItemDefinition.cxx.o Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.o Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItemDefinition.cxx.o Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/RefItem.cxx.o Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/RefItemDefinition.cxx.o /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:22:9: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' this->m_membershipMask = smtk::model::ANY_ENTITY; ~~~~ ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:36:52: error: out-of-line definition of 'membershipMask' does not match any declaration in 'smtk::attribute::MeshSelectionItemDefinition' smtk::model::BitFlags MeshSelectionItemDefinition::membershipMask() const ^~~~~~~~~~~~~~ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:38:16: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' return this->m_membershipMask; ~~~~ ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:42:35: error: out-of-line definition of 'setMembershipMask' does not match any declaration in 'smtk::attribute::MeshSelectionItemDefinition' void MeshSelectionItemDefinition::setMembershipMask(smtk::model::BitFlags entMask) ^~~~~~~~~~~~~~~~~ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:44:9: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' this->m_membershipMask = entMask; ~~~~ ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:25:3: error: use of undeclared identifier 'm_modifyMode' m_modifyMode = NONE; ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:128:9: error: no member named 'm_modifyMode' in 'smtk::attribute::MeshSelectionItem' this->m_modifyMode = sourceMeshSelectionItem->modifyMode(); ~~~~ ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:128:49: error: no member named 'modifyMode' in 'smtk::attribute::MeshSelectionItem' this->m_modifyMode = sourceMeshSelectionItem->modifyMode(); ~~~~~~~~~~~~~~~~~~~~~~~ ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:144:50: error: unknown type name 'MeshModifyMode' std::string MeshSelectionItem::modifyMode2String(MeshModifyMode m) ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:165:1: error: unknown type name 'MeshModifyMode' MeshModifyMode MeshSelectionItem::string2ModifyMode(const std::string &s) ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:187:9: error: use of undeclared identifier 'NUM_OF_MODIFYMODES'; did you mean 'NUM_OF_MODES'? return NUM_OF_MODIFYMODES; ^~~~~~~~~~~~~~~~~~ NUM_OF_MODES /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/attribute/MeshSelectionItem.h:32:3: note: 'NUM_OF_MODES' declared here NUM_OF_MODES //!< The number of mesh selection modes. ^ 5 errors generated. make[5]: *** [smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItemDefinition.cxx.o] Error 1 make[5]: *** Waiting for unfinished jobs.... 6 errors generated. make[5]: *** [smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.o] Error 1 make[4]: *** [smtk/CMakeFiles/smtkCore.dir/all] Error 2 make[3]: *** [all] Error 2 -- 2 CMake Error at /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/pv-smtk-build.cmake:27 (message): Failed!!! make[2]: *** [smtk/src/smtk-stamp/smtk-build] Error 1 make[1]: *** [CMakeFiles/smtk.dir/all] Error 2 make: *** [all] Error 2 Any ideas? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Sun May 24 18:34:42 2015 From: bob.obara at kitware.com (Bob Obara) Date: Sun, 24 May 2015 18:34:42 -0400 Subject: [Smtk-developers] Problem with SMTK Master Message-ID: Hi All, I?ve updated all of the CMB files to reflect the correct license however while building CMB SuperBuild in develop mode SMTK is giving me an error: 41%] [ 41%] [ 41%] [ 41%] [ 41%] Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/ModelEntityItemDefinition.cxx.o Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.o Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItemDefinition.cxx.o Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/RefItem.cxx.o Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/RefItemDefinition.cxx.o /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:22:9: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' this->m_membershipMask = smtk::model::ANY_ENTITY; ~~~~ ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:36:52: error: out-of-line definition of 'membershipMask' does not match any declaration in 'smtk::attribute::MeshSelectionItemDefinition' smtk::model::BitFlags MeshSelectionItemDefinition::membershipMask() const ^~~~~~~~~~~~~~ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:38:16: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' return this->m_membershipMask; ~~~~ ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:42:35: error: out-of-line definition of 'setMembershipMask' does not match any declaration in 'smtk::attribute::MeshSelectionItemDefinition' void MeshSelectionItemDefinition::setMembershipMask(smtk::model::BitFlags entMask) ^~~~~~~~~~~~~~~~~ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:44:9: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' this->m_membershipMask = entMask; ~~~~ ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:25:3: error: use of undeclared identifier 'm_modifyMode' m_modifyMode = NONE; ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:128:9: error: no member named 'm_modifyMode' in 'smtk::attribute::MeshSelectionItem' this->m_modifyMode = sourceMeshSelectionItem->modifyMode(); ~~~~ ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:128:49: error: no member named 'modifyMode' in 'smtk::attribute::MeshSelectionItem' this->m_modifyMode = sourceMeshSelectionItem->modifyMode(); ~~~~~~~~~~~~~~~~~~~~~~~ ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:144:50: error: unknown type name 'MeshModifyMode' std::string MeshSelectionItem::modifyMode2String(MeshModifyMode m) ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:165:1: error: unknown type name 'MeshModifyMode' MeshModifyMode MeshSelectionItem::string2ModifyMode(const std::string &s) ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:187:9: error: use of undeclared identifier 'NUM_OF_MODIFYMODES'; did you mean 'NUM_OF_MODES'? return NUM_OF_MODIFYMODES; ^~~~~~~~~~~~~~~~~~ NUM_OF_MODES /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/attribute/MeshSelectionItem.h:32:3: note: 'NUM_OF_MODES' declared here NUM_OF_MODES //!< The number of mesh selection modes. ^ 5 errors generated. make[5]: *** [smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItemDefinition.cxx.o] Error 1 make[5]: *** Waiting for unfinished jobs.... 6 errors generated. make[5]: *** [smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.o] Error 1 make[4]: *** [smtk/CMakeFiles/smtkCore.dir/all] Error 2 make[3]: *** [all] Error 2 -- 2 CMake Error at /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/pv-smtk-build.cmake:27 (message): Failed!!! make[2]: *** [smtk/src/smtk-stamp/smtk-build] Error 1 make[1]: *** [CMakeFiles/smtk.dir/all] Error 2 make: *** [all] Error 2 Any ideas? Bob -- Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.yuan at kitware.com Sun May 24 22:30:57 2015 From: yumin.yuan at kitware.com (yumin.yuan at kitware.com) Date: Sun, 24 May 2015 22:30:57 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: References: Message-ID: Is this a clean build? If not?you may need to do what Dave suggested in his previous email. Here is part of that email: > SMTK is about to start installing its headers into a different location (${PREFIX}/include/smtk/${SMTK_VERSION}/smtk instead of ${PREFIX}/include/smtk). CMB merge request #33 keeps CMB compiling but does require you to remove SMTK_INCLUDE_DIR from your CMB CMakeCache.txt file before rebuilding. It would also be wise to wipe the ${PREFIX}/include/smtk directory before updating+installing SMTK so that CMB doesn't find the old headers and break down the road. Yumin Sent from my iPhone > On May 24, 2015, at 6:34 PM, Bob Obara wrote: > > > Hi All, > > I?ve updated all of the CMB files to reflect the correct license however while building CMB SuperBuild in develop mode SMTK is giving me an error: > > 41%] [ 41%] [ 41%] [ 41%] [ 41%] Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/ModelEntityItemDefinition.cxx.o > Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.o > Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItemDefinition.cxx.o > Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/RefItem.cxx.o > Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/RefItemDefinition.cxx.o > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:22:9: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' > this->m_membershipMask = smtk::model::ANY_ENTITY; > ~~~~ ^ > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:36:52: error: out-of-line definition of 'membershipMask' does not match any declaration in 'smtk::attribute::MeshSelectionItemDefinition' > smtk::model::BitFlags MeshSelectionItemDefinition::membershipMask() const > ^~~~~~~~~~~~~~ > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:38:16: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' > return this->m_membershipMask; > ~~~~ ^ > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:42:35: error: out-of-line definition of 'setMembershipMask' does not match any declaration in 'smtk::attribute::MeshSelectionItemDefinition' > void MeshSelectionItemDefinition::setMembershipMask(smtk::model::BitFlags entMask) > ^~~~~~~~~~~~~~~~~ > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:44:9: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' > this->m_membershipMask = entMask; > ~~~~ ^ > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:25:3: error: use of undeclared identifier 'm_modifyMode' > m_modifyMode = NONE; > ^ > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:128:9: error: no member named 'm_modifyMode' in 'smtk::attribute::MeshSelectionItem' > this->m_modifyMode = sourceMeshSelectionItem->modifyMode(); > ~~~~ ^ > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:128:49: error: no member named 'modifyMode' in 'smtk::attribute::MeshSelectionItem' > this->m_modifyMode = sourceMeshSelectionItem->modifyMode(); > ~~~~~~~~~~~~~~~~~~~~~~~ ^ > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:144:50: error: unknown type name 'MeshModifyMode' > std::string MeshSelectionItem::modifyMode2String(MeshModifyMode m) > ^ > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:165:1: error: unknown type name 'MeshModifyMode' > MeshModifyMode MeshSelectionItem::string2ModifyMode(const std::string &s) > ^ > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:187:9: error: use of undeclared identifier 'NUM_OF_MODIFYMODES'; did you mean 'NUM_OF_MODES'? > return NUM_OF_MODIFYMODES; > ^~~~~~~~~~~~~~~~~~ > NUM_OF_MODES > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/attribute/MeshSelectionItem.h:32:3: note: 'NUM_OF_MODES' declared here > NUM_OF_MODES //!< The number of mesh selection modes. > ^ > 5 errors generated. > make[5]: *** [smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItemDefinition.cxx.o] Error 1 > make[5]: *** Waiting for unfinished jobs.... > 6 errors generated. > make[5]: *** [smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.o] Error 1 > make[4]: *** [smtk/CMakeFiles/smtkCore.dir/all] Error 2 > make[3]: *** [all] Error 2 > -- 2 > CMake Error at /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/pv-smtk-build.cmake:27 (message): > Failed!!! > > > make[2]: *** [smtk/src/smtk-stamp/smtk-build] Error 1 > make[1]: *** [CMakeFiles/smtk.dir/all] Error 2 > make: *** [all] Error 2 > > > Any ideas? > > Bob > > -- > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Mon May 25 00:26:29 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 25 May 2015 00:26:29 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: References: Message-ID: Hi Yumin, Yep, brand new super build. Bob Sent from my iPad > On May 24, 2015, at 10:30 PM, yumin.yuan at kitware.com wrote: > > Is this a clean build? If not?you may need to do what Dave suggested in his previous email. Here is part of that email: > > >> SMTK is about to start installing its headers into a different location (${PREFIX}/include/smtk/${SMTK_VERSION}/smtk instead of ${PREFIX}/include/smtk). CMB merge request #33 keeps CMB compiling but does require you to remove SMTK_INCLUDE_DIR from your CMB CMakeCache.txt file before rebuilding. It would also be wise to wipe the ${PREFIX}/include/smtk directory before updating+installing SMTK so that CMB doesn't find the old headers and break down the road. > > Yumin > Sent from my iPhone > >> On May 24, 2015, at 6:34 PM, Bob Obara wrote: >> >> >> Hi All, >> >> I?ve updated all of the CMB files to reflect the correct license however while building CMB SuperBuild in develop mode SMTK is giving me an error: >> >> 41%] [ 41%] [ 41%] [ 41%] [ 41%] Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/ModelEntityItemDefinition.cxx.o >> Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.o >> Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItemDefinition.cxx.o >> Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/RefItem.cxx.o >> Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/RefItemDefinition.cxx.o >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:22:9: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' >> this->m_membershipMask = smtk::model::ANY_ENTITY; >> ~~~~ ^ >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:36:52: error: out-of-line definition of 'membershipMask' does not match any declaration in 'smtk::attribute::MeshSelectionItemDefinition' >> smtk::model::BitFlags MeshSelectionItemDefinition::membershipMask() const >> ^~~~~~~~~~~~~~ >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:38:16: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' >> return this->m_membershipMask; >> ~~~~ ^ >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:42:35: error: out-of-line definition of 'setMembershipMask' does not match any declaration in 'smtk::attribute::MeshSelectionItemDefinition' >> void MeshSelectionItemDefinition::setMembershipMask(smtk::model::BitFlags entMask) >> ^~~~~~~~~~~~~~~~~ >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:44:9: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' >> this->m_membershipMask = entMask; >> ~~~~ ^ >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:25:3: error: use of undeclared identifier 'm_modifyMode' >> m_modifyMode = NONE; >> ^ >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:128:9: error: no member named 'm_modifyMode' in 'smtk::attribute::MeshSelectionItem' >> this->m_modifyMode = sourceMeshSelectionItem->modifyMode(); >> ~~~~ ^ >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:128:49: error: no member named 'modifyMode' in 'smtk::attribute::MeshSelectionItem' >> this->m_modifyMode = sourceMeshSelectionItem->modifyMode(); >> ~~~~~~~~~~~~~~~~~~~~~~~ ^ >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:144:50: error: unknown type name 'MeshModifyMode' >> std::string MeshSelectionItem::modifyMode2String(MeshModifyMode m) >> ^ >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:165:1: error: unknown type name 'MeshModifyMode' >> MeshModifyMode MeshSelectionItem::string2ModifyMode(const std::string &s) >> ^ >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:187:9: error: use of undeclared identifier 'NUM_OF_MODIFYMODES'; did you mean 'NUM_OF_MODES'? >> return NUM_OF_MODIFYMODES; >> ^~~~~~~~~~~~~~~~~~ >> NUM_OF_MODES >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/attribute/MeshSelectionItem.h:32:3: note: 'NUM_OF_MODES' declared here >> NUM_OF_MODES //!< The number of mesh selection modes. >> ^ >> 5 errors generated. >> make[5]: *** [smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItemDefinition.cxx.o] Error 1 >> make[5]: *** Waiting for unfinished jobs.... >> 6 errors generated. >> make[5]: *** [smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.o] Error 1 >> make[4]: *** [smtk/CMakeFiles/smtkCore.dir/all] Error 2 >> make[3]: *** [all] Error 2 >> -- 2 >> CMake Error at /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/pv-smtk-build.cmake:27 (message): >> Failed!!! >> >> >> make[2]: *** [smtk/src/smtk-stamp/smtk-build] Error 1 >> make[1]: *** [CMakeFiles/smtk.dir/all] Error 2 >> make: *** [all] Error 2 >> >> >> Any ideas? >> >> Bob >> >> -- >> Robert M. O'Bara, MEng. >> Assistant Director of Scientific Computing >> >> Kitware Inc. >> 28 Corporate Drive >> Suite 101 >> Clifton Park, NY 12065 >> >> Phone: (518) 881- 4931 >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon May 25 09:40:23 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 25 May 2015 09:40:23 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: References: Message-ID: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> Hi Bob, I see that MeshSelectionItemDefinition definitely contains m_membershipMask, so it seems likely that an old header is getting pulled from somewhere. Can you run make smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i in the SMTK build directory and then look at the result to see where it is getting headers? Thanks, David On May 25, 2015, at 12:26 AM, Robert Michael O'Bara wrote: > Hi Yumin, > Yep, brand new super build. > > Bob > Sent from my iPad > > On May 24, 2015, at 10:30 PM, yumin.yuan at kitware.com wrote: > >> Is this a clean build? If not?you may need to do what Dave suggested in his previous email. Here is part of that email: >> >> >>> SMTK is about to start installing its headers into a different location (${PREFIX}/include/smtk/${SMTK_VERSION}/smtk instead of ${PREFIX}/include/smtk). CMB merge request #33 keeps CMB compiling but does require you to remove SMTK_INCLUDE_DIR from your CMB CMakeCache.txt file before rebuilding. It would also be wise to wipe the ${PREFIX}/include/smtk directory before updating+installing SMTK so that CMB doesn't find the old headers and break down the road. >> >> Yumin >> Sent from my iPhone >> >> On May 24, 2015, at 6:34 PM, Bob Obara wrote: >> >>> >>> Hi All, >>> >>> I?ve updated all of the CMB files to reflect the correct license however while building CMB SuperBuild in develop mode SMTK is giving me an error: >>> >>> 41%] [ 41%] [ 41%] [ 41%] [ 41%] Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/ModelEntityItemDefinition.cxx.o >>> Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.o >>> Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItemDefinition.cxx.o >>> Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/RefItem.cxx.o >>> Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/RefItemDefinition.cxx.o >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:22:9: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' >>> this->m_membershipMask = smtk::model::ANY_ENTITY; >>> ~~~~ ^ >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:36:52: error: out-of-line definition of 'membershipMask' does not match any declaration in 'smtk::attribute::MeshSelectionItemDefinition' >>> smtk::model::BitFlags MeshSelectionItemDefinition::membershipMask() const >>> ^~~~~~~~~~~~~~ >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:38:16: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' >>> return this->m_membershipMask; >>> ~~~~ ^ >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:42:35: error: out-of-line definition of 'setMembershipMask' does not match any declaration in 'smtk::attribute::MeshSelectionItemDefinition' >>> void MeshSelectionItemDefinition::setMembershipMask(smtk::model::BitFlags entMask) >>> ^~~~~~~~~~~~~~~~~ >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:44:9: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' >>> this->m_membershipMask = entMask; >>> ~~~~ ^ >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:25:3: error: use of undeclared identifier 'm_modifyMode' >>> m_modifyMode = NONE; >>> ^ >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:128:9: error: no member named 'm_modifyMode' in 'smtk::attribute::MeshSelectionItem' >>> this->m_modifyMode = sourceMeshSelectionItem->modifyMode(); >>> ~~~~ ^ >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:128:49: error: no member named 'modifyMode' in 'smtk::attribute::MeshSelectionItem' >>> this->m_modifyMode = sourceMeshSelectionItem->modifyMode(); >>> ~~~~~~~~~~~~~~~~~~~~~~~ ^ >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:144:50: error: unknown type name 'MeshModifyMode' >>> std::string MeshSelectionItem::modifyMode2String(MeshModifyMode m) >>> ^ >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:165:1: error: unknown type name 'MeshModifyMode' >>> MeshModifyMode MeshSelectionItem::string2ModifyMode(const std::string &s) >>> ^ >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:187:9: error: use of undeclared identifier 'NUM_OF_MODIFYMODES'; did you mean 'NUM_OF_MODES'? >>> return NUM_OF_MODIFYMODES; >>> ^~~~~~~~~~~~~~~~~~ >>> NUM_OF_MODES >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/attribute/MeshSelectionItem.h:32:3: note: 'NUM_OF_MODES' declared here >>> NUM_OF_MODES //!< The number of mesh selection modes. >>> ^ >>> 5 errors generated. >>> make[5]: *** [smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItemDefinition.cxx.o] Error 1 >>> make[5]: *** Waiting for unfinished jobs.... >>> 6 errors generated. >>> make[5]: *** [smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.o] Error 1 >>> make[4]: *** [smtk/CMakeFiles/smtkCore.dir/all] Error 2 >>> make[3]: *** [all] Error 2 >>> -- 2 >>> CMake Error at /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/pv-smtk-build.cmake:27 (message): >>> Failed!!! >>> >>> >>> make[2]: *** [smtk/src/smtk-stamp/smtk-build] Error 1 >>> make[1]: *** [CMakeFiles/smtk.dir/all] Error 2 >>> make: *** [all] Error 2 >>> >>> >>> Any ideas? >>> >>> Bob >>> >>> -- >>> Robert M. O'Bara, MEng. >>> Assistant Director of Scientific Computing >>> >>> Kitware Inc. >>> 28 Corporate Drive >>> Suite 101 >>> Clifton Park, NY 12065 >>> >>> Phone: (518) 881- 4931 >>> _______________________________________________ >>> Smtk-developers mailing list >>> Smtk-developers at smtk.org >>> http://public.kitware.com/mailman/listinfo/smtk-developers > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers From bob.obara at kitware.com Mon May 25 13:43:14 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 25 May 2015 13:43:14 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> Message-ID: <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> More Info: Sha1 of CMBSuperBuild ; 829f41833388e47f82f12d88e0fdeb6bb47b771a SMTK in SuperBuild is at tag release-v1 From my SMTK Build Dir: make smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i make: *** No rule to make target `smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i'. Stop. Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On May 25, 2015, at 9:40 AM, David Thompson wrote: > > Hi Bob, > > I see that MeshSelectionItemDefinition definitely contains m_membershipMask, so it seems likely that an old header is getting pulled from somewhere. Can you run > > make smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i > > in the SMTK build directory and then look at the result to see where it is getting headers? > > Thanks, > David > > On May 25, 2015, at 12:26 AM, Robert Michael O'Bara wrote: > >> Hi Yumin, >> Yep, brand new super build. >> >> Bob >> Sent from my iPad >> >> On May 24, 2015, at 10:30 PM, yumin.yuan at kitware.com wrote: >> >>> Is this a clean build? If not?you may need to do what Dave suggested in his previous email. Here is part of that email: >>> >>> >>>> SMTK is about to start installing its headers into a different location (${PREFIX}/include/smtk/${SMTK_VERSION}/smtk instead of ${PREFIX}/include/smtk). CMB merge request #33 keeps CMB compiling but does require you to remove SMTK_INCLUDE_DIR from your CMB CMakeCache.txt file before rebuilding. It would also be wise to wipe the ${PREFIX}/include/smtk directory before updating+installing SMTK so that CMB doesn't find the old headers and break down the road. >>> >>> Yumin >>> Sent from my iPhone >>> >>> On May 24, 2015, at 6:34 PM, Bob Obara wrote: >>> >>>> >>>> Hi All, >>>> >>>> I?ve updated all of the CMB files to reflect the correct license however while building CMB SuperBuild in develop mode SMTK is giving me an error: >>>> >>>> 41%] [ 41%] [ 41%] [ 41%] [ 41%] Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/ModelEntityItemDefinition.cxx.o >>>> Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.o >>>> Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItemDefinition.cxx.o >>>> Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/RefItem.cxx.o >>>> Building CXX object smtk/CMakeFiles/smtkCore.dir/attribute/RefItemDefinition.cxx.o >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:22:9: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' >>>> this->m_membershipMask = smtk::model::ANY_ENTITY; >>>> ~~~~ ^ >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:36:52: error: out-of-line definition of 'membershipMask' does not match any declaration in 'smtk::attribute::MeshSelectionItemDefinition' >>>> smtk::model::BitFlags MeshSelectionItemDefinition::membershipMask() const >>>> ^~~~~~~~~~~~~~ >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:38:16: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' >>>> return this->m_membershipMask; >>>> ~~~~ ^ >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:42:35: error: out-of-line definition of 'setMembershipMask' does not match any declaration in 'smtk::attribute::MeshSelectionItemDefinition' >>>> void MeshSelectionItemDefinition::setMembershipMask(smtk::model::BitFlags entMask) >>>> ^~~~~~~~~~~~~~~~~ >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItemDefinition.cxx:44:9: error: no member named 'm_membershipMask' in 'smtk::attribute::MeshSelectionItemDefinition' >>>> this->m_membershipMask = entMask; >>>> ~~~~ ^ >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:25:3: error: use of undeclared identifier 'm_modifyMode' >>>> m_modifyMode = NONE; >>>> ^ >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:128:9: error: no member named 'm_modifyMode' in 'smtk::attribute::MeshSelectionItem' >>>> this->m_modifyMode = sourceMeshSelectionItem->modifyMode(); >>>> ~~~~ ^ >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:128:49: error: no member named 'modifyMode' in 'smtk::attribute::MeshSelectionItem' >>>> this->m_modifyMode = sourceMeshSelectionItem->modifyMode(); >>>> ~~~~~~~~~~~~~~~~~~~~~~~ ^ >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:144:50: error: unknown type name 'MeshModifyMode' >>>> std::string MeshSelectionItem::modifyMode2String(MeshModifyMode m) >>>> ^ >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:165:1: error: unknown type name 'MeshModifyMode' >>>> MeshModifyMode MeshSelectionItem::string2ModifyMode(const std::string &s) >>>> ^ >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/smtk/src/smtk/smtk/attribute/MeshSelectionItem.cxx:187:9: error: use of undeclared identifier 'NUM_OF_MODIFYMODES'; did you mean 'NUM_OF_MODES'? >>>> return NUM_OF_MODIFYMODES; >>>> ^~~~~~~~~~~~~~~~~~ >>>> NUM_OF_MODES >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/attribute/MeshSelectionItem.h:32:3: note: 'NUM_OF_MODES' declared here >>>> NUM_OF_MODES //!< The number of mesh selection modes. >>>> ^ >>>> 5 errors generated. >>>> make[5]: *** [smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItemDefinition.cxx.o] Error 1 >>>> make[5]: *** Waiting for unfinished jobs.... >>>> 6 errors generated. >>>> make[5]: *** [smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.o] Error 1 >>>> make[4]: *** [smtk/CMakeFiles/smtkCore.dir/all] Error 2 >>>> make[3]: *** [all] Error 2 >>>> -- 2 >>>> CMake Error at /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/pv-smtk-build.cmake:27 (message): >>>> Failed!!! >>>> >>>> >>>> make[2]: *** [smtk/src/smtk-stamp/smtk-build] Error 1 >>>> make[1]: *** [CMakeFiles/smtk.dir/all] Error 2 >>>> make: *** [all] Error 2 >>>> >>>> >>>> Any ideas? >>>> >>>> Bob >>>> >>>> -- >>>> Robert M. O'Bara, MEng. >>>> Assistant Director of Scientific Computing >>>> >>>> Kitware Inc. >>>> 28 Corporate Drive >>>> Suite 101 >>>> Clifton Park, NY 12065 >>>> >>>> Phone: (518) 881- 4931 >>>> _______________________________________________ >>>> Smtk-developers mailing list >>>> Smtk-developers at smtk.org >>>> http://public.kitware.com/mailman/listinfo/smtk-developers >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon May 25 13:45:04 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 25 May 2015 13:45:04 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> Message-ID: <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> > SMTK in SuperBuild is at tag release-v1 > > From my SMTK Build Dir: > make smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i > make: *** No rule to make target `smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i'. Stop. Err, sorry, that should probably be: cd smtk make CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i as the "*.cxx.i" targets only exist in Makefiles for the directory where the target was declared (smtkCore in this case). David From bob.obara at kitware.com Mon May 25 13:49:27 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 25 May 2015 13:49:27 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> Message-ID: No luck (assuming you mean cd into the smtk subdirectory of the smtk build directory: [obara at Gallifrey smtk-build]$ cd smtk [obara at Gallifrey smtk]$ make CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i make: *** No rule to make target `CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i'. Stop. Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On May 25, 2015, at 1:45 PM, David Thompson wrote: > >> SMTK in SuperBuild is at tag release-v1 >> >> From my SMTK Build Dir: >> make smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i >> make: *** No rule to make target `smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i'. Stop. > > Err, sorry, that should probably be: > > cd smtk > make CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i > > as the "*.cxx.i" targets only exist in Makefiles for the directory where the target was declared (smtkCore in this case). > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon May 25 13:53:39 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 25 May 2015 13:53:39 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> Message-ID: Grr. Verified on a local build. This should work cd smtk make attribute/MeshSelectionItem.cxx.i in the SMTK build directory (as you surmised). David > On May 25, 2015, at 1:49 PM, Robert Michael O'Bara wrote: > > No luck (assuming you mean cd into the smtk subdirectory of the smtk build directory: > > [obara at Gallifrey smtk-build]$ cd smtk > [obara at Gallifrey smtk]$ make CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i > make: *** No rule to make target `CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i'. Stop. > > Bob > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > > > > >> On May 25, 2015, at 1:45 PM, David Thompson wrote: >> >>> SMTK in SuperBuild is at tag release-v1 >>> >>> From my SMTK Build Dir: >>> make smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i >>> make: *** No rule to make target `smtk/CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i'. Stop. >> >> Err, sorry, that should probably be: >> >> cd smtk >> make CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i >> >> as the "*.cxx.i" targets only exist in Makefiles for the directory where the target was declared (smtkCore in this case). >> >> David > From bob.obara at kitware.com Mon May 25 13:59:06 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 25 May 2015 13:59:06 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> Message-ID: [obara at Gallifrey smtk]$ make attribute/MeshSelectionItem.cxx.i Preprocessing CXX source to CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On May 25, 2015, at 1:53 PM, David Thompson wrote: > > make attribute/MeshSelectionItem.cxx.i -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon May 25 14:01:03 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 25 May 2015 14:01:03 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> Message-ID: <4F458C26-F4D3-4FB0-831B-7902F7437A15@kitware.com> > [obara at Gallifrey smtk]$ make attribute/MeshSelectionItem.cxx.i > Preprocessing CXX source to CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i Great. Now look in CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i and find the absolute path of the MeshSelectionItemDefinition header being included. Is it in the superbuild's SMTK source directory? Thanks, David From bob.obara at kitware.com Mon May 25 14:35:18 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 25 May 2015 14:35:18 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: <4F458C26-F4D3-4FB0-831B-7902F7437A15@kitware.com> References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> <4F458C26-F4D3-4FB0-831B-7902F7437A15@kitware.com> Message-ID: "/Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/attribute/MeshSelectionItemDefinition.h? 2 and yes its in that directory. bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On May 25, 2015, at 2:01 PM, David Thompson wrote: > >> [obara at Gallifrey smtk]$ make attribute/MeshSelectionItem.cxx.i >> Preprocessing CXX source to CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i > > Great. Now look in CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i and find the absolute path of the MeshSelectionItemDefinition header being included. Is it in the superbuild's SMTK source directory? > > Thanks, > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon May 25 14:39:05 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 25 May 2015 14:39:05 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> <4F458C26-F4D3-4FB0-831B-7902F7437A15@kitware.com> Message-ID: <1E10A4D8-2EB6-4878-B65E-CE04FFB42E74@kitware.com> Hi Bob, > "/Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/attribute/MeshSelectionItemDefinition.h? 2 > > and yes its in that directory. But that's the install directory, not the SMTK source directory... you said it was a clean superbuild. Is that a different superbuild? Also, I would expect it to be /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/1.0.0/smtk/attribute/MeshSelectionItemDefinition.h (note the smtk/1.0.0) if you have the latest release-v1 branch of SMTK. Perhaps you did not clean out the old superbuild install directory before restarting cleanly? "rm -rf /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk" should get you compiling again... David > > >> On May 25, 2015, at 2:01 PM, David Thompson wrote: >> >>> [obara at Gallifrey smtk]$ make attribute/MeshSelectionItem.cxx.i >>> Preprocessing CXX source to CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i >> >> Great. Now look in CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i and find the absolute path of the MeshSelectionItemDefinition header being included. Is it in the superbuild's SMTK source directory? >> >> Thanks, >> David > From bob.obara at kitware.com Mon May 25 15:40:11 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 25 May 2015 15:40:11 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: <1E10A4D8-2EB6-4878-B65E-CE04FFB42E74@kitware.com> References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> <4F458C26-F4D3-4FB0-831B-7902F7437A15@kitware.com> <1E10A4D8-2EB6-4878-B65E-CE04FFB42E74@kitware.com> Message-ID: Hi David, Found my problem - thanks! Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On May 25, 2015, at 2:39 PM, David Thompson wrote: > > Hi Bob, > >> "/Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/attribute/MeshSelectionItemDefinition.h? 2 >> >> and yes its in that directory. > > But that's the install directory, not the SMTK source directory... you said it was a clean superbuild. Is that a different superbuild? > > Also, I would expect it to be > > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/1.0.0/smtk/attribute/MeshSelectionItemDefinition.h > > > (note the smtk/1.0.0) if you have the latest release-v1 branch of SMTK. Perhaps you did not clean out the old superbuild install directory before restarting cleanly? "rm -rf /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk" should get you compiling again... > > David > >> >> >>> On May 25, 2015, at 2:01 PM, David Thompson wrote: >>> >>>> [obara at Gallifrey smtk]$ make attribute/MeshSelectionItem.cxx.i >>>> Preprocessing CXX source to CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i >>> >>> Great. Now look in CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i and find the absolute path of the MeshSelectionItemDefinition header being included. Is it in the superbuild's SMTK source directory? >>> >>> Thanks, >>> David >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Mon May 25 15:45:50 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 25 May 2015 15:45:50 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> <4F458C26-F4D3-4FB0-831B-7902F7437A15@kitware.com> <1E10A4D8-2EB6-4878-B65E-CE04FFB42E74@kitware.com> Message-ID: Next problem - CMake Error at /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4Develop/paraview/src/paraview/VTK/CMake/FindPackageHandleStandardArgs.cmake:97 (MESSAGE): Could NOT find SMTK (missing: SMTK_INCLUDE_DIR) Call Stack (most recent call first): /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4Develop/paraview/src/paraview/VTK/CMake/FindPackageHandleStandardArgs.cmake:288 (_FPHSA_FAILURE_MESSAGE) CMake/FindSMTK.cmake:30 (find_package_handle_standard_args) ModelBridges/CMakeLists.txt:4 (find_package) Did you fix the developer mode of the SuperBuild when you decided to put versioning in the smtk include path? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On May 25, 2015, at 3:40 PM, Robert Michael O'Bara wrote: > > Hi David, > > Found my problem - thanks! > > Bob > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > > > > >> On May 25, 2015, at 2:39 PM, David Thompson > wrote: >> >> Hi Bob, >> >>> "/Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/attribute/MeshSelectionItemDefinition.h? 2 >>> >>> and yes its in that directory. >> >> But that's the install directory, not the SMTK source directory... you said it was a clean superbuild. Is that a different superbuild? >> >> Also, I would expect it to be >> >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/1.0.0/smtk/attribute/MeshSelectionItemDefinition.h >> >> >> (note the smtk/1.0.0) if you have the latest release-v1 branch of SMTK. Perhaps you did not clean out the old superbuild install directory before restarting cleanly? "rm -rf /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk" should get you compiling again... >> >> David >> >>> >>> >>>> On May 25, 2015, at 2:01 PM, David Thompson > wrote: >>>> >>>>> [obara at Gallifrey smtk]$ make attribute/MeshSelectionItem.cxx.i >>>>> Preprocessing CXX source to CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i >>>> >>>> Great. Now look in CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i and find the absolute path of the MeshSelectionItemDefinition header being included. Is it in the superbuild's SMTK source directory? >>>> >>>> Thanks, >>>> David >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Mon May 25 15:52:20 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 25 May 2015 15:52:20 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: <1E10A4D8-2EB6-4878-B65E-CE04FFB42E74@kitware.com> References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> <4F458C26-F4D3-4FB0-831B-7902F7437A15@kitware.com> <1E10A4D8-2EB6-4878-B65E-CE04FFB42E74@kitware.com> Message-ID: <4374E0EC-0DBF-4E5C-B1C3-FE7A9A472F10@kitware.com> I?ve got SMT_INCLUDE_DIR set - what do I now set SMTK_ROOT_DIR to? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On May 25, 2015, at 2:39 PM, David Thompson wrote: > > Hi Bob, > >> "/Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/attribute/MeshSelectionItemDefinition.h? 2 >> >> and yes its in that directory. > > But that's the install directory, not the SMTK source directory... you said it was a clean superbuild. Is that a different superbuild? > > Also, I would expect it to be > > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/1.0.0/smtk/attribute/MeshSelectionItemDefinition.h > > > (note the smtk/1.0.0) if you have the latest release-v1 branch of SMTK. Perhaps you did not clean out the old superbuild install directory before restarting cleanly? "rm -rf /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk" should get you compiling again... > > David > >> >> >>> On May 25, 2015, at 2:01 PM, David Thompson wrote: >>> >>>> [obara at Gallifrey smtk]$ make attribute/MeshSelectionItem.cxx.i >>>> Preprocessing CXX source to CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i >>> >>> Great. Now look in CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i and find the absolute path of the MeshSelectionItemDefinition header being included. Is it in the superbuild's SMTK source directory? >>> >>> Thanks, >>> David >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon May 25 15:52:21 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 25 May 2015 15:52:21 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> <4F458C26-F4D3-4FB0-831B-7902F7437A15@kitware.com> <1E10A4D8-2EB6-4878-B65E-CE04FFB42E74@kitware.com> Message-ID: <6A742853-9916-41E1-8441-47285CB0C406@kitware.com> I fixed CMB's CMake/FindSMTK.cmake file to look in the proper place but if you have a preexisting CMakeCache.txt that has SMTK_INCLUDE_DIR already defined to the old location there will be trouble. It worked for me once I removed SMTK_INCLUDE_DIR from CMB's CMakeCache.txt. If it is causing trouble I can have the superbuild explicitly specify the include dir. Also, I merged something this morning to SMTK/master (i.e., not included in CMB superbuild yet) that removes the need for FindSMTK.cmake. (SMTK will install an SMTKConfig.cmake file.) One of the reasons I did that was the buildbot superbuilds seem to be having trouble still. David > On May 25, 2015, at 3:45 PM, Robert Michael O'Bara wrote: > > Next problem - > CMake Error at /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4Develop/paraview/src/paraview/VTK/CMake/FindPackageHandleStandardArgs.cmake:97 (MESSAGE): > Could NOT find SMTK (missing: SMTK_INCLUDE_DIR) > Call Stack (most recent call first): > /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4Develop/paraview/src/paraview/VTK/CMake/FindPackageHandleStandardArgs.cmake:288 (_FPHSA_FAILURE_MESSAGE) > CMake/FindSMTK.cmake:30 (find_package_handle_standard_args) > ModelBridges/CMakeLists.txt:4 (find_package) > > Did you fix the developer mode of the SuperBuild when you decided to put versioning in the smtk include path? > > Bob > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > > > > >> On May 25, 2015, at 3:40 PM, Robert Michael O'Bara wrote: >> >> Hi David, >> >> Found my problem - thanks! >> >> Bob >> >> Robert M. O'Bara, MEng. >> Assistant Director of Scientific Computing >> >> Kitware Inc. >> 28 Corporate Drive >> Suite 101 >> Clifton Park, NY 12065 >> >> Phone: (518) 881- 4931 >> >> >> >> >>> On May 25, 2015, at 2:39 PM, David Thompson wrote: >>> >>> Hi Bob, >>> >>>> "/Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/attribute/MeshSelectionItemDefinition.h? 2 >>>> >>>> and yes its in that directory. >>> >>> But that's the install directory, not the SMTK source directory... you said it was a clean superbuild. Is that a different superbuild? >>> >>> Also, I would expect it to be >>> >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk/1.0.0/smtk/attribute/MeshSelectionItemDefinition.h >>> >>> >>> (note the smtk/1.0.0) if you have the latest release-v1 branch of SMTK. Perhaps you did not clean out the old superbuild install directory before restarting cleanly? "rm -rf /Users/obara/Projects/Kitware/Builds/CMBSuperBuildV4/install/include/smtk" should get you compiling again... >>> >>> David >>> >>>> >>>> >>>>> On May 25, 2015, at 2:01 PM, David Thompson wrote: >>>>> >>>>>> [obara at Gallifrey smtk]$ make attribute/MeshSelectionItem.cxx.i >>>>>> Preprocessing CXX source to CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i >>>>> >>>>> Great. Now look in CMakeFiles/smtkCore.dir/attribute/MeshSelectionItem.cxx.i and find the absolute path of the MeshSelectionItemDefinition header being included. Is it in the superbuild's SMTK source directory? >>>>> >>>>> Thanks, >>>>> David >>>> >>> >> > From david.thompson at kitware.com Mon May 25 15:53:42 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 25 May 2015 15:53:42 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: <4374E0EC-0DBF-4E5C-B1C3-FE7A9A472F10@kitware.com> References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> <4F458C26-F4D3-4FB0-831B-7902F7437A15@kitware.com> <1E10A4D8-2EB6-4878-B65E-CE04FFB42E74@kitware.com> <4374E0EC-0DBF-4E5C-B1C3-FE7A9A472F10@kitware.com> Message-ID: <131CA515-A1E1-4FB0-91FB-EF06B1145F6F@kitware.com> > I?ve got SMT_INCLUDE_DIR set - what do I now set SMTK_ROOT_DIR to? The superbuild/install directory. David From bob.obara at kitware.com Mon May 25 16:52:13 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 25 May 2015 16:52:13 -0400 Subject: [Smtk-developers] Problem with SMTK Master In-Reply-To: <131CA515-A1E1-4FB0-91FB-EF06B1145F6F@kitware.com> References: <95B07045-8311-4923-9328-0FD59516432F@kitware.com> <1A817B54-C85A-44A1-B9DC-58D3FD78D4F6@kitware.com> <92E82739-625F-4BFA-BE3B-09A557D5529B@kitware.com> <4F458C26-F4D3-4FB0-831B-7902F7437A15@kitware.com> <1E10A4D8-2EB6-4878-B65E-CE04FFB42E74@kitware.com> <4374E0EC-0DBF-4E5C-B1C3-FE7A9A472F10@kitware.com> <131CA515-A1E1-4FB0-91FB-EF06B1145F6F@kitware.com> Message-ID: <9BD958BC-31A2-4077-AC9B-411004127429@kitware.com> I?ve tested and committed the licensing changes. Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On May 25, 2015, at 3:53 PM, David Thompson wrote: > >> I?ve got SMT_INCLUDE_DIR set - what do I now set SMTK_ROOT_DIR to? > > The superbuild/install directory. > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue May 26 00:47:51 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 26 May 2015 00:47:51 -0400 Subject: [Smtk-developers] SMTK install Message-ID: <10C586C7-3038-4A68-BFC8-493A97C14BF2@kitware.com> Hi all, I've merged a change to master that gets SMTK installing an SMTKConfig.cmake file properly (in {prefix}/lib/cmake/SMTK/) and have used it to build a minimal external project (see below). To fix the CMB dashboards, I have submitted CMB-superbuild MR #32 [1] and CMB MR #35 [2] along with SMTK PR #187 [3]. They should be accepted all-at-once. Together, they specify a better way to find SMTK; remove the FindSMTK.cmake file from CMB; and merge SMTK/master to the release-v1 branch. David [1]: https://gitlab.kitware.com/cmb/cmb-superbuild/merge_requests/32 [2]: https://gitlab.kitware.com/cmb/cmb/merge_requests/35 [3]: https://github.com/Kitware/SMTK/pull/185 PS. A minimal project that uses an external, installed SMTK is ---------- CMakeLists.txt ---------- cmake_minimum_required(VERSION 3.2) project(foo) find_package(SMTK) add_executable(runme runme.cxx) target_link_libraries(runme smtkCore) ---------- CMakeLists.txt ---------- ---------- runme.cxx ---------- #include #include "smtk/common/Version.h" int main() { std::cout << "Compiled with SMTK version " << smtk::common::Version::number() << "\n"; return 0; } ---------- runme.cxx ---------- From bob.obara at kitware.com Tue May 26 14:40:52 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Tue, 26 May 2015 14:40:52 -0400 Subject: [Smtk-developers] SuperBuild Issues Message-ID: <66B2B99C-914C-4946-BB22-A42896E7EAE3@kitware.com> Hi David, This is a brand new SuperBuild (with both CMB and SMTK in superbuild mode) - I?m getting the following: [ 88%] Performing configure step for 'cmb' Not searching for unused variables given on the command line. -- CMAKE_CXX_COMPILER_ID='AppleClang' -- CMAKE_CXX_FLAGS='-fPIC -arch x86_64 -mmacosx-version-min=10.10 --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk' -- CMAKE_C_FLAGS='-fPIC -arch x86_64 -mmacosx-version-min=10.10 --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk' EXECUTABLE_OUTPUT_PATH=/Users/obara/Projects/Kitware/Builds/CMBSuperBuild/cmb/src/cmb-build/bin -- Boost version: 1.56.0 -- Found the following Boost libraries: -- thread -- filesystem -- system -- date_time VXL_LIBRARY_DIR=/Users/obara/Projects/Kitware/Builds/CMBSuperBuild/install/lib CMake Error at Source/ModelBridges/CMakeLists.txt:4 (find_package): By not providing "FindSMTK.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "SMTK", but CMake did not find one. Could not find a package configuration file provided by "SMTK" with any of the following names: SMTKConfig.cmake smtk-config.cmake Add the installation prefix of "SMTK" to CMAKE_PREFIX_PATH or set "SMTK_DIR" to a directory containing one of the above files. If "SMTK" provides a separate development package or SDK, be sure it has been installed. -- Configuring incomplete, errors occurred! See also "/Users/obara/Projects/Kitware/Builds/CMBSuperBuild/cmb/src/cmb-build/CMakeFiles/CMakeOutput.log". See also "/Users/obara/Projects/Kitware/Builds/CMBSuperBuild/cmb/src/cmb-build/CMakeFiles/CMakeError.log". Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue May 26 14:45:00 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 26 May 2015 14:45:00 -0400 Subject: [Smtk-developers] SuperBuild Issues In-Reply-To: <66B2B99C-914C-4946-BB22-A42896E7EAE3@kitware.com> References: <66B2B99C-914C-4946-BB22-A42896E7EAE3@kitware.com> Message-ID: <2B2EA1B5-A834-4F24-8630-740C6345E00C@kitware.com> Hi Bob, > This is a brand new SuperBuild (with both CMB and SMTK in superbuild mode) - I?m getting the following: There should be an SMTKConfig.cmake file in /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/install/lib/cmake/SMTK . 1. Is it there? 2. If not, can you add 'message("SMTK config in ${smtk_dir}")' line to Projects/cmb.cmake in your superbuild source and tell me what it prints? Thanks, David > > [ 88%] Performing configure step for 'cmb' > Not searching for unused variables given on the command line. > -- CMAKE_CXX_COMPILER_ID='AppleClang' > -- CMAKE_CXX_FLAGS='-fPIC -arch x86_64 -mmacosx-version-min=10.10 --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk' > -- CMAKE_C_FLAGS='-fPIC -arch x86_64 -mmacosx-version-min=10.10 --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk' > EXECUTABLE_OUTPUT_PATH=/Users/obara/Projects/Kitware/Builds/CMBSuperBuild/cmb/src/cmb-build/bin > -- Boost version: 1.56.0 > -- Found the following Boost libraries: > -- thread > -- filesystem > -- system > -- date_time > VXL_LIBRARY_DIR=/Users/obara/Projects/Kitware/Builds/CMBSuperBuild/install/lib > CMake Error at Source/ModelBridges/CMakeLists.txt:4 (find_package): > By not providing "FindSMTK.cmake" in CMAKE_MODULE_PATH this project has > asked CMake to find a package configuration file provided by "SMTK", but > CMake did not find one. > > Could not find a package configuration file provided by "SMTK" with any of > the following names: > > SMTKConfig.cmake > smtk-config.cmake > > Add the installation prefix of "SMTK" to CMAKE_PREFIX_PATH or set > "SMTK_DIR" to a directory containing one of the above files. If "SMTK" > provides a separate development package or SDK, be sure it has been > installed. > > > -- Configuring incomplete, errors occurred! > See also "/Users/obara/Projects/Kitware/Builds/CMBSuperBuild/cmb/src/cmb-build/CMakeFiles/CMakeOutput.log". > See also "/Users/obara/Projects/Kitware/Builds/CMBSuperBuild/cmb/src/cmb-build/CMakeFiles/CMakeError.log". > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > > > > From bob.obara at kitware.com Tue May 26 14:51:54 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Tue, 26 May 2015 14:51:54 -0400 Subject: [Smtk-developers] SuperBuild Issues In-Reply-To: <2B2EA1B5-A834-4F24-8630-740C6345E00C@kitware.com> References: <66B2B99C-914C-4946-BB22-A42896E7EAE3@kitware.com> <2B2EA1B5-A834-4F24-8630-740C6345E00C@kitware.com> Message-ID: Yep - there is a SMTK subdirectory in that directory: EncodeCStringFunctions.cmake SMTKOperatorXML.cmake SMTKSessionJSON.cmake Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On May 26, 2015, at 2:45 PM, David Thompson wrote: > > Hi Bob, > >> This is a brand new SuperBuild (with both CMB and SMTK in superbuild mode) - I?m getting the following: > > There should be an SMTKConfig.cmake file in /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/install/lib/cmake/SMTK . > > 1. Is it there? > 2. If not, can you add 'message("SMTK config in ${smtk_dir}")' line to Projects/cmb.cmake in your superbuild source and tell me what it prints? > > Thanks, > David > >> >> [ 88%] Performing configure step for 'cmb' >> Not searching for unused variables given on the command line. >> -- CMAKE_CXX_COMPILER_ID='AppleClang' >> -- CMAKE_CXX_FLAGS='-fPIC -arch x86_64 -mmacosx-version-min=10.10 --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk' >> -- CMAKE_C_FLAGS='-fPIC -arch x86_64 -mmacosx-version-min=10.10 --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk' >> EXECUTABLE_OUTPUT_PATH=/Users/obara/Projects/Kitware/Builds/CMBSuperBuild/cmb/src/cmb-build/bin >> -- Boost version: 1.56.0 >> -- Found the following Boost libraries: >> -- thread >> -- filesystem >> -- system >> -- date_time >> VXL_LIBRARY_DIR=/Users/obara/Projects/Kitware/Builds/CMBSuperBuild/install/lib >> CMake Error at Source/ModelBridges/CMakeLists.txt:4 (find_package): >> By not providing "FindSMTK.cmake" in CMAKE_MODULE_PATH this project has >> asked CMake to find a package configuration file provided by "SMTK", but >> CMake did not find one. >> >> Could not find a package configuration file provided by "SMTK" with any of >> the following names: >> >> SMTKConfig.cmake >> smtk-config.cmake >> >> Add the installation prefix of "SMTK" to CMAKE_PREFIX_PATH or set >> "SMTK_DIR" to a directory containing one of the above files. If "SMTK" >> provides a separate development package or SDK, be sure it has been >> installed. >> >> >> -- Configuring incomplete, errors occurred! >> See also "/Users/obara/Projects/Kitware/Builds/CMBSuperBuild/cmb/src/cmb-build/CMakeFiles/CMakeOutput.log". >> See also "/Users/obara/Projects/Kitware/Builds/CMBSuperBuild/cmb/src/cmb-build/CMakeFiles/CMakeError.log". >> >> Robert M. O'Bara, MEng. >> Assistant Director of Scientific Computing >> >> Kitware Inc. >> 28 Corporate Drive >> Suite 101 >> Clifton Park, NY 12065 >> >> Phone: (518) 881- 4931 >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue May 26 14:57:36 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 26 May 2015 14:57:36 -0400 Subject: [Smtk-developers] SuperBuild Issues In-Reply-To: References: <66B2B99C-914C-4946-BB22-A42896E7EAE3@kitware.com> <2B2EA1B5-A834-4F24-8630-740C6345E00C@kitware.com> Message-ID: <1C9B30FD-620B-40EC-B615-F6F01524AE1D@kitware.com> > Yep - there is a SMTK subdirectory in that directory: > EncodeCStringFunctions.cmake SMTKOperatorXML.cmake SMTKSessionJSON.cmake Hmmm... and yet if SMTK is up to date, there should also be an SMTKConfig.cmake file there. Is your SMTK source at SHA b04d9c? (Yumin merged the PR this morning @ 8:45a.) David From bob.obara at kitware.com Tue May 26 15:01:03 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Tue, 26 May 2015 15:01:03 -0400 Subject: [Smtk-developers] SuperBuild Issues In-Reply-To: <1C9B30FD-620B-40EC-B615-F6F01524AE1D@kitware.com> References: <66B2B99C-914C-4946-BB22-A42896E7EAE3@kitware.com> <2B2EA1B5-A834-4F24-8630-740C6345E00C@kitware.com> <1C9B30FD-620B-40EC-B615-F6F01524AE1D@kitware.com> Message-ID: Nope - its from my rebase as of last night. Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On May 26, 2015, at 2:57 PM, David Thompson wrote: > >> Yep - there is a SMTK subdirectory in that directory: >> EncodeCStringFunctions.cmake SMTKOperatorXML.cmake SMTKSessionJSON.cmake > > Hmmm... and yet if SMTK is up to date, there should also be an SMTKConfig.cmake file there. Is your SMTK source at SHA b04d9c? (Yumin merged the PR this morning @ 8:45a.) > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: