[slicer-users] [slicer-devel] important: repository changes for slicer4 and slicer3.6
pieper at bwh.harvard.edu
Thu Sep 23 13:21:47 EDT 2010
Interesting - I'll try a build too on mac and see what happens.
p.s. follow-ups to slicer-devel only ;)
On 09/23/2010 12:08 PM, Daniel Haehn wrote:
> Hi Steve,
> great work!
> I just checked out the new Slicer4 trunk and performed a SuperBuild. In general it worked fine!
> Unfortunately, I still had to compile python manually on my Mac (PythonQT enabled) to prevent the following error:
> [ 0%] Built target vtkWrapHierarchy
> make: *** No rule to make target `/Users/daniel/SLICER/QT_TRUNK/Slicer4-SuperBuild/python-build/lib/libpython2.6.dylib', needed by `bin/vtkWrapPython'. Stop.
> make: *** [Wrapping/CMakeFiles/vtkWrapPython.dir/all] Error 2
> make: *** [all] Error 2
> make: *** [VTK-prefix/src/VTK-stamp/VTK-build] Error 2
> make: *** [CMakeFiles/VTK.dir/all] Error 2
> make: *** [all] Error 2
> Anyway, I updated the Slicer 4 Build instructions on the wiki:
> (I also updated the QT links to v4.7 which was released 2 days ago..)
> On Sep 22, 2010, at 2:50 PM, Steve Pieper wrote:
>> [Note: this is information is important for people using the slicer svn
>> repositories. I cc'd slicer-users just to be sure I catch everyone who
>> is impacted - if you don't know/care what a slicer svn repository is,
>> feel free to ignore this message... Followups and future messages on
>> this topic will go to slicer-devel only.]
>> *Summary:* there is now a Slicer4 svn repository  which is a copy of
>> the Slicer3 trunk as of earlier today. The Slicer3 existing trunk will
>> soon be used only for slicer 3.6 maintenance purposes.
>>  http://svn.slicer.org/Slicer4
>> *Background:* Slicer4  is a significant re-write of the user
>> interface to use Qt. Along the way, several structural improvements to
>> the non-UI code are being made as well. Until now, we had been
>> maintaining the ability to build either a KWWidgets-based GUI or a
>> Qt-based GUI on the same code base in the Slicer3 svn trunk. Having
>> both Slicer3 and Slicer4 both hosted in a repository named "Slicer3" has
>> been, frankly, confusing. But it was useful, since many changes
>> impacted both versions. As the code has progressed this is no longer
>> needed so the two code streams will now diverge. Essentially the
>> Slicer3 code will remain stable with the exception of fixes for the
>> issues identified for fixes in the 3.6.x patch releases .
>>  http://www.slicer.org/slicerWiki/index.php/Slicer4
>>  http://www.slicer.org/slicerWiki/index.php/Slicer3:3.6_Final_Issues
>> *Changes to the Slicer3 svn*
>> By the end of the day today I expect to have the following layout in the
>> Slicer3 svn. Please take care to adjust your practices accordingly.
>> http://svn.slicer.org/Slicer3/oldtrunk - will be trunk at the time I
>> make the change (this is a backup as a place to find code that was
>> committed to the trunk after revision 15031 when the Slicer4 repository
>> was created).
>> http://svn.slicer.org/Slicer3/trunk - will be a copy of
>> *Nightly builds*
>> Recently the nightly slicer builds have been unstable because because
>> they were built from the Slicer3 trunk which included both bug fixes
>> intended for 3.6.x and reworked code intended for 4. In the coming
>> weeks we will be start making two sets of nightly builds: one for
>> Slicer3.6.2-beta and one for Slicer4-alpha. The "3.7" numbering from
>> the current nightly builds will no longer be used.
>> The process for developers working on 3.6.x bug fixes should be:
>> - test your fixes on a checkout from the (new) Slicer3 trunk
>> - point users to the nightly builds for testing
>> - if the tests are good, merge the code to the Slicer-3-6 branch.
>> - if the fixes apply to slicer4, they should also be merged to the
>> Slicer4 trunk
>> Dashboard machines should point to the Slicer3 trunk for testing Slicer3
>> or to the Slicer4 trunk for testing Slicer4 (see how much more logical
>> that is?). In the coming weeks we plan to set up a new set of nightly
>> builds of Slicer4 on various platforms.
>> *The future of the Slicer4 svn repository*
>> In the coming months we will be stripping away the KWWidgets code from
>> slicer4 as well as the getbuildtest build system (People should already
>> be using the SuperBuild approach exclusively when building slicer4).
>> There will be many more exciting improvements too. Stay tuned...
>> Hope this is all clear for the people who need to act on this info.
>> Please send follow-up info or questions to the slicer-devel list.
>> slicer-devel mailing list
>> slicer-devel at bwh.harvard.edu
>> To unsubscribe: send email to slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the subject
More information about the slicer-users