Slicer3:Installing - Revision history

Grundlett: Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

2017-07-10T18:04:27Z

Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

Marianna: Protected "Slicer3:Installing" [edit=sysop:move=sysop]

2008-05-22T16:10:24Z

Protected "Slicer3:Installing" [edit=sysop:move=sysop]

Marianna: Unprotected "Slicer3:Installing"

2008-05-19T21:23:28Z

Unprotected "Slicer3:Installing"

Marianna: Replacing page with ''''Note:''' We are migrating this content to the slicer.org domain - The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:Installing ...'

2008-05-19T21:23:20Z

Replacing page with '<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:Installing ...'

Barre: New page: This page is intended to sum up the issues we need to tackle in order to create Slicer3 installers. This first draft is a copy of Sebastien Barre's email to the Slicer3 developpers list......

2007-09-26T17:14:15Z

New page: This page is intended to sum up the issues we need to tackle in order to create Slicer3 installers. This first draft is a copy of Sebastien Barre's email to the Slicer3 developpers list......

New page

This page is intended to sum up the issues we need to tackle in order to create Slicer3 installers.
This first draft is a copy of Sebastien Barre's email to the Slicer3 developpers list...

As we discussed during the Clifton Park meeting, I would suggest making sure the INSTALL target is creating a standalone installation directory that Slicer3 can be launched from. Once that is working, CPack's work is pretty much done, as it will basically tar/gzip the whole thing, or wrap it inside a (NSIS) Windows installer.

I just ran a "nmake install" on a Win32 build, Debug and Release (not a static one, since we decided to stick to shared build the last time we met in Salt Lake City). Both ended being identical (which is good), but there are a few issues we need to solve:

* Slicer3.exe: the launcher doesn't work, as it tries to run Slicer3-real.exe in bin\Release\ (or bin\Debug\), and executables are now in bin\. This problem is related to something we discussed Steve and I already, where people building Slicer3 with 'nmake' can't use the toplevel Slicer3.exe to launch the application anyway. And by people I mean probably "only Sebastien" :) But solving this problem will solve the install tree problem as well :)

* bin\:
** the SlicerTractographySeeding.dll ends up in bin\, instead of lib\Slicer3\Plugins\,
** a fair amount of *.lib files are installed in bin\: they should either be *not* installed, or installed in lib\Slicer3\ if we want to let people build modules/plugins against an installed tree (in that case we would need to install the headers in include\Slicer3\ as well). I would recommend not installing for the moment.

* lib\
** ModuleDescriptionParser.lib (see above, since we are not installing the headers, this probably should not be installed either; this can be controlled using an option, we have such a framework in VTK/ITK/KWW, and/or we could create two installers, one for development, one just for the turn-key standalone Slicer3 app).
** there a few files in lib\. I would recommend moving them to lib\Slicer3\, so that they don't collide with other installation trees (say, if you were to install to /usr/local ultimately). Maybe you guys recall that one of the first Slicer3 installation scripts went really wrong last year as we were trying to create release candidates for the SLC meeting late at night: even as of last week, I'm still finding bits and pieces of it in my /usr/local :) This is something I know ITK and KWW do correctly (i.e. you will notice include/KWWidgets/, lib/KWWidgets/, include/InsightTookit/, lib/InsightToolkit/), VTK got it right for its include/ dir, but still puts its *.lib files in lib/ (it is *configurable* though). Now for *.lib files, we can discuss the benefit of putting them in lib/ versus lib/Slicer3/: the former probably makes the linker's life easier for people who already have /usr/local/lib in their lib path. I found the later cleaner, especially on Unix systems. VTK even put its version number after the directory name (i.e. include/vtk-5.0); ITK and KWW do not. In any case, files that are not *.lib like lib/launch.tcl should, in my opinion, really be in lib/Slicer3/, as such common filenames could easily collide with another installed package, and 6 months later it would be hard to remember that it was part of Slicer3 if you were to uninstall the package by hand.

* lib\Slicer3\Plugins:
** SlicerTractographySeeding.dll missing here (see bin\),
** EMSegmentCommandLine_GUIVersionLib.dll isn't installed as well,
** GEDicom2NRRDLib.dll and GEDicom2NRRD.exe are not,
** LabelMapSmoothing.dll is not,
** ZeroCrossingBasedEdgeDetectionImageFilterLib.dll and ZeroCrossingBasedEdgeDetectionImageFilter.exe are not,
** Diffusion*.exe (4 files) are not,
** ProbeVolumeWithModel.exe is not

* Libs\:
** it's hard to tell what's going on here: the Libs\ directory in the build tree is full of files that are either compiled, configured and/or generated; What should be installed will only be obvious to module maintainers I guess, maybe we want to simplify that. Also, having two lib-related directories (lib/ and Libs/) looks a tad confusing to me; If there are support files to be installed (typically color transfer functions, presets, etc), I would put them in a share/Slicer3/ directory (as done in KWW and some other toolkits).
** same as lib/, I would recommend moving files Libs/Slicer3/, or share/Slicer3/, to play nicely with other installation trees.
** so far I see only Libs\FreeSurfer installed.

← Older revision		Revision as of 18:04, 10 July 2017
Line 1:		Line 1:
−	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [~~http~~://www.slicer.org/~~slicerWiki/index.php~~/Slicer3:Installing here]</font></big>a	+	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [https://www.slicer.org/wiki/Slicer3:Installing here]</font></big>a

← Older revision		Revision as of 21:23, 19 May 2008
Line 1:		Line 1:
−	~~This page is intended to sum up the issues we need to tackle in order to create Slicer3 installers.~~	+	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:Installing here]</font></big>a
−	~~This first draft is a copy of Sebastien Barre~~'~~s email to the Slicer3 developpers list...~~
−
−	As we discussed during the Clifton Park meeting, I would suggest making sure the INSTALL target is creating a standalone installation directory that Slicer3 can be launched from. Once that is working, CPack'~~s work is pretty much done, as it will basically tar/gzip the whole thing, or wrap it inside a (NSIS) Windows installer.~~
−
−	I just ran a "nmake install" on a Win32 build, Debug and Release (not a static one, since we decided to stick to shared build the last time we met in Salt Lake City). Both ended being identical (which is good), but there are a few issues we need to solve:
−
−	* Slicer3.exe: the launcher doesn't work, as it tries to run Slicer3-real.exe in bin\Release\ (or bin\Debug\), and executables are now in bin\. This problem is related to something we discussed Steve and I already, where people building Slicer3 with '~~nmake~~' ~~can~~'~~t use the toplevel Slicer3.exe~~ to ~~launch~~ the ~~application anyway~~. ~~And by people I mean probably~~ "~~only Sebastien~~" :~~) But solving this problem will solve the install tree problem as well :)~~
−
−	* bin\:
−	** the SlicerTractographySeeding.dll ends up in bin\, instead of lib\Slicer3\Plugins\,
−	** a fair amount of .lib files are installed in bin\: they should either be not* installed, or installed in lib\Slicer3\ if we want to let people build modules/~~plugins against an installed tree (in that case we would need to install the headers in include\Slicer3\ as well). I would recommend not installing for the moment.~~
−
−	* lib\
−	** ModuleDescriptionParser.lib (see above, since we are not installing the headers, this probably should not be installed either; this can be controlled using an option, we have such a framework in VTK/ITK/KWW, and/~~or we could create two installers, one for development, one just for the turn-key standalone Slicer3 app)~~.
−	** there a few files in lib\. ~~I would recommend moving them to lib\Slicer3\, so that they don't collide with other installation trees (say, if you were to install to~~ /~~usr~~/~~local ultimately)~~. Maybe you guys recall that one of the first Slicer3 installation scripts went really wrong last year as we were trying to create release candidates for the SLC meeting late at night: even as of last week, I'm still finding bits and pieces of it in my /usr/local :) This is something I know ITK and KWW do correctly (i.e. you will notice include/KWWidgets/, lib/KWWidgets/, include/InsightTookit/, lib/InsightToolkit/), VTK got it right for its include/ dir, but still puts its .lib files in lib/ (it is configurable* though). Now for .lib files, we can discuss the benefit of putting them in lib/ versus lib/Slicer3/: ~~the former probably makes the linker's life easier for people who already have /usr/local/lib in their lib path.~~ I found the later cleaner, especially on Unix systems. VTK even put its version number after the directory name (i.e. include/vtk-5.0); ITK and KWW do not. In any case, files that are not .lib like lib/launch.tcl should, in my opinion, really be in lib/Slicer3/, as such common filenames could easily collide with another installed package, and 6 months later it would be hard to remember that it was part of Slicer3 if you were to uninstall the package by hand.
−
−	* lib\Slicer3\Plugins:
−	** SlicerTractographySeeding.dll missing here (see bin\),
−	** EMSegmentCommandLine_GUIVersionLib.dll isn't installed as well,
−	** GEDicom2NRRDLib.dll and GEDicom2NRRD.exe are not,
−	** LabelMapSmoothing.dll is not,
−	** ZeroCrossingBasedEdgeDetectionImageFilterLib.dll and ZeroCrossingBasedEdgeDetectionImageFilter.exe are not,
−	** Diffusion*.exe (4 files) are not,
−	** ProbeVolumeWithModel.exe is not
−
−	* Libs\:
−	** it's hard to tell what's going on here~~: the Libs\ directory in the build tree is full of files that are either compiled, configured and~~/~~or generated; What should be installed will only be obvious to module maintainers I guess, maybe we want to simplify that. Also, having two lib-related directories (lib~~/ ~~and Libs/) looks~~ a tad confusing to me; If there are support files to be installed (typically color transfer functions, presets, etc), I would put them in a share/Slicer3/ directory (as done in KWW and some other toolkits).
−	** same as lib/, I would recommend moving files Libs/Slicer3/, or share/Slicer3/, to play nicely with other installation trees.
−	** so far I see only Libs\FreeSurfer installed.

← Older revision	Revision as of 16:10, 22 May 2008
(No difference)