2008 Winter Project Week:CPack - Revision history

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

2017-07-10T18:07:13Z

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

Melonakos at 01:38, 6 November 2008

2008-11-06T01:38:44Z

Barre: /* January 2008 Project Week */

2008-02-14T19:53:49Z

January 2008 Project Week

Barre at 17:58, 7 February 2008

2008-02-07T17:58:26Z

Hayes: /* January 2008 Project Week */

2008-01-31T19:43:42Z

January 2008 Project Week

Hayes: /* January 2008 Project Week */

2008-01-31T19:43:00Z

January 2008 Project Week

Hayes: /* January 2008 Project Week */

2008-01-31T19:34:41Z

January 2008 Project Week

Hayes: /* C-tools vs. getbuildtest build strategies make continuing support for CPack and compiling difficult. */

2008-01-11T00:21:46Z

C-tools vs. getbuildtest build strategies make continuing support for CPack and compiling difficult.

Hayes: /* C-tools vs. getbuildtest build strategies make continuing support for CPack and compiling difficult. */

2008-01-11T00:21:01Z

C-tools vs. getbuildtest build strategies make continuing support for CPack and compiling difficult.

Hayes at 23:49, 10 January 2008

2008-01-10T23:49:45Z

@@ Line 41: / Line 41: @@
 *We had a productive meeting about the future of the getbuildtest scripts and whether or not that functionality can be moved entirely within the CMake infrastructure.
-*We are looking into creating a "NA-MICSetup" program, akin to Cygwin's setup program, that will offer different versions of Slicer for different users, including end users, [http://www.slicer.org/slicerWiki/index.php/Slicer3:Build/Modules module] developers, core developers, and Dashboard machines.  This program will also allow more flexibility in choosing different versions of support libraries during the compilation process.  Our next task for this project is to develop a design requirements document, which we expect will be complete in the next 3-4 months.
+*We are looking into creating a "NA-MICSetup" program, akin to Cygwin's setup program, that will offer different versions of Slicer for different users, including end users, [https://www.slicer.org/wiki/Slicer3:Build/Modules module] developers, core developers, and Dashboard machines.  This program will also allow more flexibility in choosing different versions of support libraries during the compilation process.  Our next task for this project is to develop a design requirements document, which we expect will be complete in the next 3-4 months.
-* Experiments with the new BuildSystem and downloadable modules are described in the [http://www.slicer.org/slicerWiki/index.php/Slicer3:Build/Modules Slicer3:Build/Modules] page and can be found in [http://www.na-mic.org/ViewVC/index.cgi/trunk/BuildSystem/?root=NAMICSandBox NAMICSandBox/BuildSystem]. A few FILE(DOWNLOAD) command has been added to CMake, and (heavily commented) CMake macros are committed to the Sandbox to test technical feasibility.
+* Experiments with the new BuildSystem and downloadable modules are described in the [https://www.slicer.org/wiki/Slicer3:Build/Modules Slicer3:Build/Modules] page and can be found in [http://www.na-mic.org/ViewVC/index.cgi/trunk/BuildSystem/?root=NAMICSandBox NAMICSandBox/BuildSystem]. A few FILE(DOWNLOAD) command has been added to CMake, and (heavily commented) CMake macros are committed to the Sandbox to test technical feasibility.
 </div>
@@ Line 73: / Line 73: @@
 * CMake/CPack support for "NAMICSetup" executable instead of running ctest -S
-* Like Cygwin setup - do you want to be: "End User", "[http://www.slicer.org/slicerWiki/index.php/Slicer3:Build/Modules Module] Developer", "Dashboard", "Uber Developer"
+* Like Cygwin setup - do you want to be: "End User", "[https://www.slicer.org/wiki/Slicer3:Build/Modules Module] Developer", "Dashboard", "Uber Developer"
 * Need design requirements document/wiki page for NAMICSetup
 * Timeline - 3-4 months?
 ==Additional feedback/bug reports?==

@@ Line 41: / Line 41: @@
 *We had a productive meeting about the future of the getbuildtest scripts and whether or not that functionality can be moved entirely within the CMake infrastructure.
-*We are looking into creating a "NA-MICSetup" program, akin to Cygwin's setup program, that will offer different versions of Slicer for different users, including end users, [[Slicer3:Build/Modules|module]] developers, core developers, and Dashboard machines.  This program will also allow more flexibility in choosing different versions of support libraries during the compilation process.  Our next task for this project is to develop a design requirements document, which we expect will be complete in the next 3-4 months.
+*We are looking into creating a "NA-MICSetup" program, akin to Cygwin's setup program, that will offer different versions of Slicer for different users, including end users, [http://www.slicer.org/slicerWiki/index.php/Slicer3:Build/Modules module] developers, core developers, and Dashboard machines.  This program will also allow more flexibility in choosing different versions of support libraries during the compilation process.  Our next task for this project is to develop a design requirements document, which we expect will be complete in the next 3-4 months.
-* Experiments with the new BuildSystem and downloadable modules are described in the [[Slicer3:Build/Modules|Slicer3:Build/Modules]] page and can be found in [http://www.na-mic.org/ViewVC/index.cgi/trunk/BuildSystem/?root=NAMICSandBox NAMICSandBox/BuildSystem]. A few FILE(DOWNLOAD) command has been added to CMake, and (heavily commented) CMake macros are committed to the Sandbox to test technical feasibility.
+* Experiments with the new BuildSystem and downloadable modules are described in the [http://www.slicer.org/slicerWiki/index.php/Slicer3:Build/Modules Slicer3:Build/Modules] page and can be found in [http://www.na-mic.org/ViewVC/index.cgi/trunk/BuildSystem/?root=NAMICSandBox NAMICSandBox/BuildSystem]. A few FILE(DOWNLOAD) command has been added to CMake, and (heavily commented) CMake macros are committed to the Sandbox to test technical feasibility.
 </div>
@@ Line 73: / Line 73: @@
 * CMake/CPack support for "NAMICSetup" executable instead of running ctest -S
-* Like Cygwin setup - do you want to be: "End User", "[[Slicer3:Build/Modules|Module]] Developer", "Dashboard", "Uber Developer"
+* Like Cygwin setup - do you want to be: "End User", "[http://www.slicer.org/slicerWiki/index.php/Slicer3:Build/Modules Module] Developer", "Dashboard", "Uber Developer"
 * Need design requirements document/wiki page for NAMICSetup
 * Timeline - 3-4 months?
 ==Additional feedback/bug reports?==

← Older revision		Revision as of 19:53, 14 February 2008
Line 43:		Line 43:
	*We are looking into creating a "NA-MICSetup" program, akin to Cygwin's setup program, that will offer different versions of Slicer for different users, including end users, [[Slicer3:Build/Modules\|module]] developers, core developers, and Dashboard machines. This program will also allow more flexibility in choosing different versions of support libraries during the compilation process. Our next task for this project is to develop a design requirements document, which we expect will be complete in the next 3-4 months.		*We are looking into creating a "NA-MICSetup" program, akin to Cygwin's setup program, that will offer different versions of Slicer for different users, including end users, [[Slicer3:Build/Modules\|module]] developers, core developers, and Dashboard machines. This program will also allow more flexibility in choosing different versions of support libraries during the compilation process. Our next task for this project is to develop a design requirements document, which we expect will be complete in the next 3-4 months.

		+	* Experiments with the new BuildSystem and downloadable modules are described in the [[Slicer3:Build/Modules\|Slicer3:Build/Modules]] page and can be found in [http://www.na-mic.org/ViewVC/index.cgi/trunk/BuildSystem/?root=NAMICSandBox NAMICSandBox/BuildSystem]. A few FILE(DOWNLOAD) command has been added to CMake, and (heavily commented) CMake macros are committed to the Sandbox to test technical feasibility.

	</div>		</div>

@@ Line 41: / Line 41: @@
 *We had a productive meeting about the future of the getbuildtest scripts and whether or not that functionality can be moved entirely within the CMake infrastructure.
-*We are looking into creating a "NA-MICSetup" program, akin to Cygwin's setup program, that will offer different versions of Slicer for different users, including end users, module developers, core developers, and Dashboard machines.  This program will also allow more flexibility in choosing different versions of support libraries during the compilation process.  Our next task for this project is to develop a design requirements document, which we expect will be complete in the next 3-4 months.
+*We are looking into creating a "NA-MICSetup" program, akin to Cygwin's setup program, that will offer different versions of Slicer for different users, including end users, [[Slicer3:Build/Modules|module]] developers, core developers, and Dashboard machines.  This program will also allow more flexibility in choosing different versions of support libraries during the compilation process.  Our next task for this project is to develop a design requirements document, which we expect will be complete in the next 3-4 months.
@@ Line 72: / Line 72: @@
 * CMake/CPack support for "NAMICSetup" executable instead of running ctest -S
-* Like Cygwin setup - do you want to be: "End User", "Module Developer", "Dashboard", "Uber Developer"
+* Like Cygwin setup - do you want to be: "End User", "[[Slicer3:Build/Modules|Module]] Developer", "Dashboard", "Uber Developer"
 * Need design requirements document/wiki page for NAMICSetup
 * Timeline - 3-4 months?
 ==Additional feedback/bug reports?==

@@ Line 29: / Line 29: @@
 ====January 2008 Project Week====
-During the project week, we fixed some outstanding CMake/CPack issues.  These changes are not going to be back ported into CMake 2.4.2, but will be made available in future releases.  Most of these issues will be resolved when Slicer moves to CMake version 2.6.0.
+*During the project week, we fixed some outstanding CMake/CPack issues.  These changes are not going to be back ported into CMake 2.4.2, but will be made available in future releases.  Most of these issues will be resolved when Slicer moves to CMake version 2.6.0.
-During the project meeting, we tagged the official Slicer version 3.0 release.  The builds from this branch are the official stable release for Slicer 3.0, and are available [http://slicer.org/pages/Special:Slicer_Downloads/Release here].
+*During the project meeting, we tagged the official Slicer version 3.0 release.  The builds from this branch are the official stable release for Slicer 3.0, and are available [http://slicer.org/pages/Special:Slicer_Downloads/Release here].
-Other changes in the build infrastructure from the project week include moving many of the Slicer3 support libraries to newer versions.  These versions are still being tested to ensure compatibility.  We are planning to move Tcl and Tk to version 8.4.17 or 8.5.  We are also planning on moving CMake to the latest 2.4.x release, and to 2.6 when it is released.
+*Other changes in the build infrastructure from the project week include moving many of the Slicer3 support libraries to newer versions.  These versions are still being tested to ensure compatibility.  We are planning to move Tcl and Tk to version 8.4.17 or 8.5.  We are also planning on moving CMake to the latest 2.4.x release, and to 2.6 when it is released.
-RPM and .deb support will be in CMake version 2.6, as will fixes for STGZ issues on some Linux platforms.  We are planning on testing the beta CMake 2.6 when it becomes available.
+*RPM and .deb support will be in CMake version 2.6, as will fixes for STGZ issues on some Linux platforms.  We are planning on testing the beta CMake 2.6 when it becomes available.
-We will also move to newer versions of VTK and ITK, the specific version numbers and release dates are TBA.
+*We will also move to newer versions of VTK and ITK, the specific version numbers and release dates are TBA.
-We had a productive meeting about the future of the getbuildtest scripts and whether or not that functionality can be moved entirely within the CMake infrastructure.
+*We had a productive meeting about the future of the getbuildtest scripts and whether or not that functionality can be moved entirely within the CMake infrastructure.
-We are looking into creating a "NA-MICSetup" program, akin to Cygwin's setup program, that will offer different versions of Slicer for different users, including end users, module developers, core developers, and Dashboard machines.  This program will also allow more flexibility in choosing different versions of support libraries during the compilation process.  Our next task for this project is to develop a design requirements document, which we expect will be complete in the next 3-4 months.
+*We are looking into creating a "NA-MICSetup" program, akin to Cygwin's setup program, that will offer different versions of Slicer for different users, including end users, module developers, core developers, and Dashboard machines.  This program will also allow more flexibility in choosing different versions of support libraries during the compilation process.  Our next task for this project is to develop a design requirements document, which we expect will be complete in the next 3-4 months.
@@ Line 49: / Line 49: @@
 </div>
 ===Outstanding CPack Issues and Bugs===

← Older revision		Revision as of 19:43, 31 January 2008
Line 32:		Line 32:

	During the project meeting, we tagged the official Slicer version 3.0 release. The builds from this branch are the official stable release for Slicer 3.0, and are available [http://slicer.org/pages/Special:Slicer_Downloads/Release here].		During the project meeting, we tagged the official Slicer version 3.0 release. The builds from this branch are the official stable release for Slicer 3.0, and are available [http://slicer.org/pages/Special:Slicer_Downloads/Release here].
		+
		+	Other changes in the build infrastructure from the project week include moving many of the Slicer3 support libraries to newer versions. These versions are still being tested to ensure compatibility. We are planning to move Tcl and Tk to version 8.4.17 or 8.5. We are also planning on moving CMake to the latest 2.4.x release, and to 2.6 when it is released.
		+
		+	RPM and .deb support will be in CMake version 2.6, as will fixes for STGZ issues on some Linux platforms. We are planning on testing the beta CMake 2.6 when it becomes available.
		+
		+	We will also move to newer versions of VTK and ITK, the specific version numbers and release dates are TBA.
		+
		+	We had a productive meeting about the future of the getbuildtest scripts and whether or not that functionality can be moved entirely within the CMake infrastructure.
		+
		+	We are looking into creating a "NA-MICSetup" program, akin to Cygwin's setup program, that will offer different versions of Slicer for different users, including end users, module developers, core developers, and Dashboard machines. This program will also allow more flexibility in choosing different versions of support libraries during the compilation process. Our next task for this project is to develop a design requirements document, which we expect will be complete in the next 3-4 months.

← Older revision		Revision as of 19:34, 31 January 2008
Line 29:		Line 29:

	====January 2008 Project Week====		====January 2008 Project Week====
−	~~TBA~~	+	During the project week, we fixed some outstanding CMake/CPack issues. These changes are not going to be back ported into CMake 2.4.2, but will be made available in future releases. Most of these issues will be resolved when Slicer moves to CMake version 2.6.0.
		+
		+	During the project meeting, we tagged the official Slicer version 3.0 release. The builds from this branch are the official stable release for Slicer 3.0, and are available [http://slicer.org/pages/Special:Slicer_Downloads/Release here].

@@ Line 39: / Line 39: @@
-== Outstanding CPack Issues and Bugs ==
+===Outstanding CPack Issues and Bugs===
 Gathered for AHM 2008 in Salt Lake City.
 Issues:
-# Katie is hand editing some ITK 3.4 files - niftilib and znzlib cmake_install.cmake files
+==Katie is hand editing some ITK 3.4 files - niftilib and znzlib cmake_install.cmake files==
 * Katie is testing changes to ITK to fix this bug.
-# Jim and Sebastien - ongoing
+==Jim and Sebastien - ongoing==
-# RPM support needs testing / validation
+==RPM support needs testing / validation==
 * Awaiting CMake release 2.6.0
-# Some 32-bit Linux platforms are having trouble with self-extracting STGZ installer, see [http://www.na-mic.org/Bug/view.php?id=126 this bug report.]
+==Some 32-bit Linux platforms are having trouble with self-extracting STGZ installer, see [http://www.na-mic.org/Bug/view.php?id=126 this bug report.]==
-# Windows installer is adding to the Path environment variable in spite of being told not to (seen on Slicer3 for Cmake 2.4.2 and 2.4.7)
+==Windows installer is adding to the Path environment variable in spite of being told not to (seen on Slicer3 for Cmake 2.4.2 and 2.4.7)==
-# Building Slicer3 against an installed VTK rather than a build tree causes trouble; see [http://massmail.spl.harvard.edu/pipermail/slicer-devel/2007/002086.html mail trail from slicer-devel.]
+==Building Slicer3 against an installed VTK rather than a build tree causes trouble; see [http://massmail.spl.harvard.edu/pipermail/slicer-devel/2007/002086.html mail trail from slicer-devel.]==
 * Sebastien is on the case, see [http://www.na-mic.org/Bug/view.php?id=176 bug report]
-# C-tools vs. getbuildtest build strategies make continuing support for CPack and compiling difficult.
+==C-tools vs. getbuildtest build strategies make continuing support for CPack and compiling difficult.==
 * CMake/CPack support for "NAMICSetup" executable instead of running ctest -S
 * Like Cygwin setup - do you want to be: "End User", "Module Developer", "Dashboard", "Uber Developer"
-# Additional feedback/bug reports?
+==Additional feedback/bug reports?==