From bob.obara at kitware.com Tue Sep 13 16:08:42 2016 From: bob.obara at kitware.com (Bob Obara) Date: Tue, 13 Sep 2016 16:08:42 -0400 Subject: [Cmb-users] Xcode 8 Message-ID: Hi All, As you may have seen XCode 8 was released today - just to remind everyone that CMB and SMTK have not been tested with this version - so upgrade at your own risk ! (on the other hand if you have already upgraded let us know what your experience has been :) 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 jacob.becker at kitware.com Tue Sep 13 22:36:24 2016 From: jacob.becker at kitware.com (Jacob Becker) Date: Tue, 13 Sep 2016 22:36:24 -0400 Subject: [Cmb-users] Xcode 8 In-Reply-To: References: Message-ID: It appears my mac decided it wants to update it without my permission.... Juda On Tue, Sep 13, 2016 at 4:08 PM, Bob Obara wrote: > Hi All, > > As you may have seen XCode 8 was released today - just to remind everyone > that CMB and SMTK have not been tested with this version - so upgrade at > your own risk ! (on the other hand if you have already upgraded let us > know what your experience has been :) > > 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 > > > > > > _______________________________________________ > Cmb-users mailing list > Cmb-users at computationalmodelbuilder.org > http://public.kitware.com/mailman/listinfo/cmb-users > > -- =================== Jacob "Juda" Becker R&D Engineer Kitware Inc. 28 Corporate Drive Clifton Park, NY 12065 Phone: (518) 881-4947 Fax: (518) 271-4573 =================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Tue Sep 13 22:40:53 2016 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Tue, 13 Sep 2016 22:40:53 -0400 Subject: [Cmb-users] Xcode 8 In-Reply-To: References: Message-ID: <3E8E7C4B-BE88-41CE-8E1C-E2CF5A742CD7@kitware.com> Hi Juda, Oops! So I'm guessing you will be our Xcode 8 tester - I'll be very interested in the results.. Bob Sent from my iPad > On Sep 13, 2016, at 10:36 PM, Jacob Becker wrote: > > It appears my mac decided it wants to update it without my permission.... > Juda > >> On Tue, Sep 13, 2016 at 4:08 PM, Bob Obara wrote: >> Hi All, >> >> As you may have seen XCode 8 was released today - just to remind everyone that CMB and SMTK have not been tested with this version - so upgrade at your own risk ! (on the other hand if you have already upgraded let us know what your experience has been :) >> >> 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 >> >> >> >> >> >> _______________________________________________ >> Cmb-users mailing list >> Cmb-users at computationalmodelbuilder.org >> http://public.kitware.com/mailman/listinfo/cmb-users > > > > -- > =================== > Jacob "Juda" Becker > R&D Engineer > > Kitware Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > > Phone: (518) 881-4947 > Fax: (518) 271-4573 > =================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.becker at kitware.com Tue Sep 13 22:41:43 2016 From: jacob.becker at kitware.com (Jacob Becker) Date: Tue, 13 Sep 2016 22:41:43 -0400 Subject: [Cmb-users] Xcode 8 In-Reply-To: <3E8E7C4B-BE88-41CE-8E1C-E2CF5A742CD7@kitware.com> References: <3E8E7C4B-BE88-41CE-8E1C-E2CF5A742CD7@kitware.com> Message-ID: I am trying to get it to stop, so we will see. Juda On Tue, Sep 13, 2016 at 10:40 PM, Robert Michael O'Bara < bob.obara at kitware.com> wrote: > Hi Juda, > > Oops! So I'm guessing you will be our Xcode 8 tester - I'll be very > interested in the results.. > > Bob > > Sent from my iPad > > On Sep 13, 2016, at 10:36 PM, Jacob Becker > wrote: > > It appears my mac decided it wants to update it without my permission.... > Juda > > On Tue, Sep 13, 2016 at 4:08 PM, Bob Obara wrote: > >> Hi All, >> >> As you may have seen XCode 8 was released today - just to remind everyone >> that CMB and SMTK have not been tested with this version - so upgrade at >> your own risk ! (on the other hand if you have already upgraded let us >> know what your experience has been :) >> >> 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 >> >> >> >> >> >> _______________________________________________ >> Cmb-users mailing list >> Cmb-users at computationalmodelbuilder.org >> http://public.kitware.com/mailman/listinfo/cmb-users >> >> > > > -- > =================== > Jacob "Juda" Becker > R&D Engineer > > Kitware Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > > Phone: (518) 881-4947 > Fax: (518) 271-4573 > =================== > > -- =================== Jacob "Juda" Becker R&D Engineer Kitware Inc. 28 Corporate Drive Clifton Park, NY 12065 Phone: (518) 881-4947 Fax: (518) 271-4573 =================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.becker at kitware.com Tue Sep 13 22:44:19 2016 From: jacob.becker at kitware.com (Jacob Becker) Date: Tue, 13 Sep 2016 22:44:19 -0400 Subject: [Cmb-users] Xcode 8 In-Reply-To: References: <3E8E7C4B-BE88-41CE-8E1C-E2CF5A742CD7@kitware.com> Message-ID: ok, so it looks like I was successful at stopping it. I figure others should keep an eye out just incase. Juda On Tue, Sep 13, 2016 at 10:41 PM, Jacob Becker wrote: > I am trying to get it to stop, so we will see. > Juda > > On Tue, Sep 13, 2016 at 10:40 PM, Robert Michael O'Bara < > bob.obara at kitware.com> wrote: > >> Hi Juda, >> >> Oops! So I'm guessing you will be our Xcode 8 tester - I'll be very >> interested in the results.. >> >> Bob >> >> Sent from my iPad >> >> On Sep 13, 2016, at 10:36 PM, Jacob Becker >> wrote: >> >> It appears my mac decided it wants to update it without my permission.... >> Juda >> >> On Tue, Sep 13, 2016 at 4:08 PM, Bob Obara wrote: >> >>> Hi All, >>> >>> As you may have seen XCode 8 was released today - just to remind >>> everyone that CMB and SMTK have not been tested with this version - so >>> upgrade at your own risk ! (on the other hand if you have already upgraded >>> let us know what your experience has been :) >>> >>> 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 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Cmb-users mailing list >>> Cmb-users at computationalmodelbuilder.org >>> http://public.kitware.com/mailman/listinfo/cmb-users >>> >>> >> >> >> -- >> =================== >> Jacob "Juda" Becker >> R&D Engineer >> >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park, NY 12065 >> >> Phone: (518) 881-4947 >> Fax: (518) 271-4573 >> =================== >> >> > > > -- > =================== > Jacob "Juda" Becker > R&D Engineer > > Kitware Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > > Phone: (518) 881-4947 > Fax: (518) 271-4573 > =================== > -- =================== Jacob "Juda" Becker R&D Engineer Kitware Inc. 28 Corporate Drive Clifton Park, NY 12065 Phone: (518) 881-4947 Fax: (518) 271-4573 =================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Sep 14 08:28:27 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 14 Sep 2016 08:28:27 -0400 Subject: [Cmb-users] Xcode 8 In-Reply-To: References: Message-ID: <20160914122827.GA2676@megas.kitware.com> On Tue, Sep 13, 2016 at 16:08:42 -0400, Bob Obara wrote: > As you may have seen XCode 8 was released today - just to remind > everyone that CMB and SMTK have not been tested with this version - so > upgrade at your own risk ! (on the other hand if you have already > upgraded let us know what your experience has been :) It appears that 10.10 can't get the Xcode 8. --Ben From bob.obara at kitware.com Fri Sep 16 10:30:27 2016 From: bob.obara at kitware.com (Bob Obara) Date: Fri, 16 Sep 2016 10:30:27 -0400 Subject: [Cmb-users] CMBTesting Data Message-ID: Hi All, The simulation_workflow directory was added using the ssh URL - I?ve changed it to use the https version so buildbots don?t have an issue. So you will need to do a git pull and then do a git submodule sync. 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 ben.boeckel at kitware.com Fri Sep 16 16:50:59 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 16 Sep 2016 16:50:59 -0400 Subject: [Cmb-users] New superbuild layout Message-ID: <20160916205059.GA4983@megas.kitware.com> Hi, As some of you have noticed, the superbuild build tree layout has changed a bit. The new setup is (using zlib as an example): superbuild/zlib/src/zlib -> superbuild/zlib/src superbuild/zlib/src/zlib-build -> superbuild/zlib/build superbuild/zlib/src/zlib-stamp -> superbuild/zlib/stamp The easiest way to address any issues you see is to just delete the install/ directory. The more surgical fix is to delete Python bits from the install/ tree (it's the only one I saw which got headers mixed up, but other projects may have similar problems). As a reminder, do not do development underneath the superbuild unless you know what you're doing[1]: the superbuild assumes it has full control of the $builddir/superbuild directory. For SMTK and CMB, the `SMTK_SOURCE_DIR` and `CMB_SOURCE_DIR` variables may be used by setting `smtk_FROM_GIT=OFF` and `smtk_FROM_SOURCE_DIR=ON` (similar for CMB) so that you can use the superbuild for arbitrary branches. Open issues if other projects need similar treatment on a regular basis. --Ben [1]In particular, changing the source URL for git repos or the tarball for non-git sources (or switching between the two) will remove the corresponding source tree without asking. From bob.obara at kitware.com Tue Sep 20 15:40:09 2016 From: bob.obara at kitware.com (Bob Obara) Date: Tue, 20 Sep 2016 15:40:09 -0400 Subject: [Cmb-users] Updated SuperBuild Message-ID: Hi All, I?ve updated the version of ParaView we use with CMB and SMTK (to fix some incompatibilities with the latest version of ParaView Master) so if you are pulling from either SMTK or CMB master branches you will probably need to do a clean SuperBuild (either full or developer). 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 ben.boeckel at kitware.com Thu Sep 22 11:16:23 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 22 Sep 2016 11:16:23 -0400 Subject: [Cmb-users] Unused files in the repository Message-ID: <20160922151623.GA3866@megas.kitware.com> Hi, I've found the following files which are unused. Should they stay around and if so, why aren't they built? These files have no CMake code at all for them: Source/Applications/AppCommon/Scene/IO/pqCMBSceneV1Writer.* Source/Applications/AppCommon/pqCMBLIDARDataImporter.* Source/Applications/ModelBuilder/Testing/Cxx/* Source/Applications/ModelBuilder/pqCMBServerResource.* Source/VTKExtensions/Client/vtkPVGMSRegionArrayInformation.* Source/VTKExtensions/Client/vtkSMCMBPolylineRepresentationProxy.* Source/VTKExtensions/Client/vtkSMLIDARMultiFilesReaderProxy.cxx (no associated header exists) Source/Utilities/LookupTableTest/* There are also two executable with a readme, but no code to build them. What should be done with these: Source/LIDAR/cmbTerrainExtract.cxx Source/LIDAR/cmbTokenRefine.cxx Thanks, --Ben From yumin.yuan at kitware.com Thu Sep 22 11:46:39 2016 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Thu, 22 Sep 2016 11:46:39 -0400 Subject: [Cmb-users] Unused files in the repository In-Reply-To: <20160922151623.GA3866@megas.kitware.com> References: <20160922151623.GA3866@megas.kitware.com> Message-ID: Hi Ben, See inline responses, On Thu, Sep 22, 2016 at 11:16 AM, Ben Boeckel wrote: > Hi, > > I've found the following files which are unused. Should they stay around > and if so, why aren't they built? > > These files have no CMake code at all for them: > > Source/Applications/AppCommon/Scene/IO/pqCMBSceneV1Writer.* > Source/Applications/AppCommon/pqCMBLIDARDataImporter.* > Source/Applications/ModelBuilder/Testing/Cxx/* > Source/Applications/ModelBuilder/pqCMBServerResource.* > Source/VTKExtensions/Client/vtkPVGMSRegionArrayInformation.* > Source/VTKExtensions/Client/vtkSMCMBPolylineRepresentationProxy.* > Source/VTKExtensions/Client/vtkSMLIDARMultiFilesReaderProxy.cxx (no > associated header exists) > Source/Utilities/LookupTableTest/* > > I think it is safe to remove them. > There are also two executable with a readme, but no code to build them. > What should be done with these: > > Source/LIDAR/cmbTerrainExtract.cxx > Source/LIDAR/cmbTokenRefine.cxx > > I believe they were offered as an option for ERDC to use from command line. We probably should at least build them as executables, and a test will be even better :) Yumin > > --Ben > _______________________________________________ > Cmb-users mailing list > Cmb-users at computationalmodelbuilder.org > http://public.kitware.com/mailman/listinfo/cmb-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Thu Sep 22 11:55:26 2016 From: bob.obara at kitware.com (Bob Obara) Date: Thu, 22 Sep 2016 11:55:26 -0400 Subject: [Cmb-users] Unused files in the repository In-Reply-To: References: <20160922151623.GA3866@megas.kitware.com> Message-ID: I would keep the lookuptable test in that it is used to test the random lookup table generator in CMB - which we should probably be using to set the initial colors :) 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 Sep 22, 2016, at 11:46 AMEDT, Yumin Yuan wrote: > > Hi Ben, > > See inline responses, > > On Thu, Sep 22, 2016 at 11:16 AM, Ben Boeckel > wrote: > Hi, > > I've found the following files which are unused. Should they stay around > and if so, why aren't they built? > > These files have no CMake code at all for them: > > Source/Applications/AppCommon/Scene/IO/pqCMBSceneV1Writer.* > Source/Applications/AppCommon/pqCMBLIDARDataImporter.* > Source/Applications/ModelBuilder/Testing/Cxx/* > Source/Applications/ModelBuilder/pqCMBServerResource.* > Source/VTKExtensions/Client/vtkPVGMSRegionArrayInformation.* > Source/VTKExtensions/Client/vtkSMCMBPolylineRepresentationProxy.* > Source/VTKExtensions/Client/vtkSMLIDARMultiFilesReaderProxy.cxx (no > associated header exists) > Source/Utilities/LookupTableTest/* > > > I think it is safe to remove them. > > There are also two executable with a readme, but no code to build them. > What should be done with these: > > Source/LIDAR/cmbTerrainExtract.cxx > Source/LIDAR/cmbTokenRefine.cxx > > I believe they were offered as an option for ERDC to use from command line. We probably should at least build them as executables, and a test will be even better :) > > Yumin > > > --Ben > _______________________________________________ > Cmb-users mailing list > Cmb-users at computationalmodelbuilder.org > http://public.kitware.com/mailman/listinfo/cmb-users > > _______________________________________________ > Cmb-users mailing list > Cmb-users at computationalmodelbuilder.org > http://public.kitware.com/mailman/listinfo/cmb-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil.n.carlson at gmail.com Sat Sep 24 19:31:41 2016 From: neil.n.carlson at gmail.com (Neil Carlson) Date: Sat, 24 Sep 2016 17:31:41 -0600 Subject: [Cmb-users] Superbuild questions Message-ID: I have a few questions related to updating/rebuilding cmb/smtk. 1. When cmb-superbuild is cloned (and submodules updated) does it pull in the current master head versions of cmb and smtk? 2. To update my cmb-superbuild repo what do I need to do beyond 'git pull'? I'm specifically thinking of the submodules; I've not encountered them before. 3. I'm going to be testing model-builder on a workflow being developed, so I expect I'm going to want to be pulling in the latest changes on cmb/smtk. What I'd like, is to use cmb-superbuild to build and package just the TPLs, which I can stick somewhere, and then build cmb/smtk from their repos, pointing to the TPL installation. I'm sure this must be one of the workflows, but I don't know how to do it. I noted the DEVELOPER_MODE_{cmb,smtk} cmake variables, which I suspect are relevant somehow. Thanks, Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Sat Sep 24 19:45:18 2016 From: david.thompson at kitware.com (David Thompson) Date: Sat, 24 Sep 2016 19:45:18 -0400 Subject: [Cmb-users] Superbuild questions In-Reply-To: References: Message-ID: Hi Neil, > I have a few questions related to updating/rebuilding cmb/smtk. > > 1. When cmb-superbuild is cloned (and submodules updated) does it pull in the current master head versions of cmb and smtk? That depends on whether you have set the superbuild to developer mode or not. The default is not developer mode, which will fetch CMB and SMTK into the superbuild's **build tree** (i.e., not the superbuild source). They are currently both pulling the master branches, but that is likely to change. > > 2. To update my cmb-superbuild repo what do I need to do beyond 'git pull'? I'm specifically thinking of the submodules; I've not encountered them before. Yes, the superbuild recently changed and you need to 1. Run "git submodule update --init" in the source directory after pulling, and 2. Remove the "install" directory of any existing superbuild's build tree. You should always do #1 when updating the superbuild. #2 is because of some recent changes and you should always need to do this, although it is a good step to try when hitting build issues. > 3. I'm going to be testing model-builder on a workflow being developed, so I expect I'm going to want to be pulling in the latest changes on cmb/smtk. What I'd like, is to use cmb-superbuild to build and package just the TPLs, which I can stick somewhere, and then build cmb/smtk from their repos, pointing to the TPL installation. I'm sure this must be one of the workflows, but I don't know how to do it. I noted the DEVELOPER_MODE_{cmb,smtk} cmake variables, which I suspect are relevant somehow. Yes, when the DEVELOPER_MODE_xxx variables are set, then only TPL libraries are built; you are expected to build CMB and/or SMTK elsewhere. Take care when you do this because you must use the same TPLs everywhere. On my machine, I will get system versions of boost, hdf5, gdal, etc. when I build SMTK without explicitly pointing CMakeCache.txt to the superbuild. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Sep 26 13:18:40 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 26 Sep 2016 13:18:40 -0400 Subject: [Cmb-users] Superbuild questions In-Reply-To: References: Message-ID: <20160926171840.GA29376@megas.kitware.com> On Sat, Sep 24, 2016 at 19:45:18 -0400, David Thompson wrote: > > 1. When cmb-superbuild is cloned (and submodules updated) does it > > pull in the current master head versions of cmb and smtk? No, they are not cloned as part of the superbuild itself; the build will default to building the master branches though. > That depends on whether you have set the superbuild to developer mode > or not. The default is not developer mode, which will fetch CMB and > SMTK into the superbuild's **build tree** (i.e., not the superbuild > source). They are currently both pulling the master branches, but that > is likely to change. This is by default. There are also `smtk_FROM_GIT` (default to ON) and `smtk_FROM_SOURCE_DIR` (defaults to OFF and only available if `smtk_FROM_GIT` is also OFF). If both are OFF, it will try to fetch the latest release's tarball (which doesn't exist right now). If you are using git, you can use `smtk_GIT_REPOSITORY` and `smtk_GIT_TAG` (though these might have upper case names now, that should be changing with backwards support; use what you see in the editor) to whatever you want. If you want to use the superbuild with a custom SMTK build, use `smtk_FROM_SOURCE_DIR` and point it at whatever source tree you want. This is what you want if you want to test out custom binaries with an arbitrary SMTK and/or CMB. CMB has the same set of flags with the obvious name replacements. The rule of thumb is that if it is outside the superbuild build tree, it's safe, but underneath it is fair game for the superbuild to do whatever it wants to those directories. > 2. Remove the "install" directory of any existing superbuild's build tree. For safety with this step, also remove `superbuild/*/stamp/*-install` so that the superbuild knows it needs to reinstall all the projects. > You should always do #1 when updating the superbuild. #2 is because of > some recent changes and you should always need to do this, although it > is a good step to try when hitting build issues. > > > 3. I'm going to be testing model-builder on a workflow being > > developed, so I expect I'm going to want to be pulling in the latest > > changes on cmb/smtk. What I'd like, is to use cmb-superbuild to > > build and package just the TPLs, which I can stick somewhere, and > > then build cmb/smtk from their repos, pointing to the TPL > > installation. I'm sure this must be one of the workflows, but I > > don't know how to do it. I noted the DEVELOPER_MODE_{cmb,smtk} cmake > > variables, which I suspect are relevant somehow. > > Yes, when the DEVELOPER_MODE_xxx variables are set, then only TPL > libraries are built; you are expected to build CMB and/or SMTK > elsewhere. Take care when you do this because you must use the same > TPLs everywhere. On my machine, I will get system versions of boost, > hdf5, gdal, etc. when I build SMTK without explicitly pointing > CMakeCache.txt to the superbuild. Yes, the superbuild build dumps an "smtk-developer-config.cmake" into its build tree which you use with `cmake -C .../smtk-developer-config.cmake ...` to make SMTK use it (and again, obvious name changes for CMB as well). You may need to set the environment up to use the superbuild's tree (particularly PYTHONPATH and, on Windows, PATH). --Ben From bob.obara at kitware.com Mon Sep 26 13:58:46 2016 From: bob.obara at kitware.com (Bob Obara) Date: Mon, 26 Sep 2016 13:58:46 -0400 Subject: [Cmb-users] Superbuild questions In-Reply-To: <20160926171840.GA29376@megas.kitware.com> References: <20160926171840.GA29376@megas.kitware.com> Message-ID: This discussion should probably be put on the CMB SuperBuild Wiki(as FAQ regarding using the SuperBuild) and a reference in the CMB SuperBuild Readme. 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 Sep 26, 2016, at 1:18 PMEDT, Ben Boeckel wrote: > > On Sat, Sep 24, 2016 at 19:45:18 -0400, David Thompson wrote: >>> 1. When cmb-superbuild is cloned (and submodules updated) does it >>> pull in the current master head versions of cmb and smtk? > > No, they are not cloned as part of the superbuild itself; the build will > default to building the master branches though. > >> That depends on whether you have set the superbuild to developer mode >> or not. The default is not developer mode, which will fetch CMB and >> SMTK into the superbuild's **build tree** (i.e., not the superbuild >> source). They are currently both pulling the master branches, but that >> is likely to change. > > This is by default. There are also `smtk_FROM_GIT` (default to ON) and > `smtk_FROM_SOURCE_DIR` (defaults to OFF and only available if > `smtk_FROM_GIT` is also OFF). If both are OFF, it will try to fetch the > latest release's tarball (which doesn't exist right now). If you are > using git, you can use `smtk_GIT_REPOSITORY` and `smtk_GIT_TAG` (though > these might have upper case names now, that should be changing with > backwards support; use what you see in the editor) to whatever you want. > If you want to use the superbuild with a custom SMTK build, use > `smtk_FROM_SOURCE_DIR` and point it at whatever source tree you want. > This is what you want if you want to test out custom binaries with an > arbitrary SMTK and/or CMB. CMB has the same set of flags with the > obvious name replacements. > > The rule of thumb is that if it is outside the superbuild build tree, > it's safe, but underneath it is fair game for the superbuild to do > whatever it wants to those directories. > >> 2. Remove the "install" directory of any existing superbuild's build tree. > > For safety with this step, also remove `superbuild/*/stamp/*-install` so > that the superbuild knows it needs to reinstall all the projects. > >> You should always do #1 when updating the superbuild. #2 is because of >> some recent changes and you should always need to do this, although it >> is a good step to try when hitting build issues. >> >>> 3. I'm going to be testing model-builder on a workflow being >>> developed, so I expect I'm going to want to be pulling in the latest >>> changes on cmb/smtk. What I'd like, is to use cmb-superbuild to >>> build and package just the TPLs, which I can stick somewhere, and >>> then build cmb/smtk from their repos, pointing to the TPL >>> installation. I'm sure this must be one of the workflows, but I >>> don't know how to do it. I noted the DEVELOPER_MODE_{cmb,smtk} cmake >>> variables, which I suspect are relevant somehow. >> >> Yes, when the DEVELOPER_MODE_xxx variables are set, then only TPL >> libraries are built; you are expected to build CMB and/or SMTK >> elsewhere. Take care when you do this because you must use the same >> TPLs everywhere. On my machine, I will get system versions of boost, >> hdf5, gdal, etc. when I build SMTK without explicitly pointing >> CMakeCache.txt to the superbuild. > > Yes, the superbuild build dumps an "smtk-developer-config.cmake" into > its build tree which you use with `cmake -C > .../smtk-developer-config.cmake ...` to make SMTK use it (and again, > obvious name changes for CMB as well). You may need to set the > environment up to use the superbuild's tree (particularly PYTHONPATH > and, on Windows, PATH). > > --Ben > _______________________________________________ > Cmb-users mailing list > Cmb-users at computationalmodelbuilder.org > http://public.kitware.com/mailman/listinfo/cmb-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Sep 26 14:16:48 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 26 Sep 2016 14:16:48 -0400 Subject: [Cmb-users] Superbuild questions In-Reply-To: References: <20160926171840.GA29376@megas.kitware.com> Message-ID: <20160926181648.GA7894@megas.kitware.com> On Mon, Sep 26, 2016 at 13:58:46 -0400, Bob Obara wrote: > This discussion should probably be put on the CMB SuperBuild Wiki(as > FAQ regarding using the SuperBuild) and a reference in the CMB > SuperBuild Readme. Probably just the readme directly. Or as an FAQ file in the repo. --Ben From ben.boeckel at kitware.com Mon Sep 26 16:19:47 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 26 Sep 2016 16:19:47 -0400 Subject: [Cmb-users] Unused files in the repository In-Reply-To: <20160922151623.GA3866@megas.kitware.com> References: <20160922151623.GA3866@megas.kitware.com> Message-ID: <20160926201946.GA17455@megas.kitware.com> On Thu, Sep 22, 2016 at 11:16:23 -0400, Ben Boeckel wrote: > I've found the following files which are unused. Should they stay around > and if so, why aren't they built? > > These files have no CMake code at all for them: > > Source/Applications/AppCommon/Scene/IO/pqCMBSceneV1Writer.* > Source/Applications/AppCommon/pqCMBLIDARDataImporter.* > Source/Applications/ModelBuilder/Testing/Cxx/* > Source/Applications/ModelBuilder/pqCMBServerResource.* > Source/VTKExtensions/Client/vtkPVGMSRegionArrayInformation.* > Source/VTKExtensions/Client/vtkSMCMBPolylineRepresentationProxy.* > Source/VTKExtensions/Client/vtkSMLIDARMultiFilesReaderProxy.cxx (no > associated header exists) > Source/Utilities/LookupTableTest/* There were lots more under VTKExtensions. See the merge request here: https://gitlab.kitware.com/cmb/cmb/merge_requests/239 Full list of removed files: Source/VTKExtensions/Client/vtkPVGMSRegionArrayInformation.cxx Source/VTKExtensions/Client/vtkPVGMSRegionArrayInformation.h Source/VTKExtensions/Client/vtkSMCMBPolylineRepresentationProxy.cxx Source/VTKExtensions/Client/vtkSMCMBPolylineRepresentationProxy.h Source/VTKExtensions/Client/vtkSMLIDARMultiFilesReaderProxy.cxx Source/VTKExtensions/General/CMakeLists.txt Source/VTKExtensions/General/vtkCMBPolyDataSource.cxx Source/VTKExtensions/General/vtkCMBPolyDataSource.h Source/VTKExtensions/General/vtkDateFormatter.cxx Source/VTKExtensions/General/vtkDateFormatter.h Source/VTKExtensions/General/vtkDateTime.cxx Source/VTKExtensions/General/vtkDateTime.h Source/VTKExtensions/Graphics/vtkCMBPolylineActor.cxx Source/VTKExtensions/Graphics/vtkCMBPolylineActor.h Source/VTKExtensions/Graphics/vtkCMBPolylineRepresentation.cxx Source/VTKExtensions/Graphics/vtkCMBPolylineRepresentation.h Source/VTKExtensions/Graphics/vtkModelFaceActor.cxx Source/VTKExtensions/Graphics/vtkModelFaceActor.h Source/VTKExtensions/IO/vtkCMB3dmReader.cxx Source/VTKExtensions/IO/vtkCMB3dmReader.h Source/VTKExtensions/IO/vtkKMLExporter.cxx Source/VTKExtensions/IO/vtkKMLExporter.h Source/VTKExtensions/IO/vtkKMLReader.cxx Source/VTKExtensions/IO/vtkKMLReader.h Source/VTKExtensions/IO/vtkLIDARMultiFilesReader.cxx Source/VTKExtensions/IO/vtkLIDARMultiFilesReader.h Source/VTKExtensions/Testing/ArcServerMergeTest.cxx Source/VTKExtensions/Testing/ArcVisChesapeakeTest1.cxx Source/VTKExtensions/Testing/ArcVisChesapeakeTest2.cxx Source/VTKExtensions/Testing/ArcVisChesapeakeTest3.cxx Source/VTKExtensions/Testing/ArcVisMergeTest1.cxx Source/VTKExtensions/Testing/ArcVisMeshTest1.cxx Source/VTKExtensions/Testing/ArcVisMeshTest2.cxx Source/VTKExtensions/Testing/ArcVisMoveTest.cxx Source/VTKExtensions/Testing/ArcVisSplitTest.cxx Source/VTKExtensions/Testing/ArcVisUpdateTest1.cxx Source/VTKExtensions/Testing/ArcVisUpdateTest2.cxx --Ben