[IGSTK-Developers] Sandbox decoupling

[Julien Jomier]

Hi Luis,

I very much like the idea of tagging the cvs repository.
Sometimes it is a pain to retrieve a specific version in CVS.

Julien

Luis Ibanez wrote:
> 
> Hi Julien,
> 
> I would discourage the practice of commenting out lines, both in C++
> files and in CMakeLists.txt files.
> 
> If we need to recover something later, then we can use CVS to recover
> older versions. That's after all one of the great benefits of using
> CVS.  Commenting out lines is not a mechanism that we can maintain
> over the years. That is, two years from now, nobody will know exactly
> why those lines are commented out, and whether they should be removed
> or restored. If restored they probably will not work anymore because
> the rest of the toolkit would have evolved and the lines may not even
> match the syntax of the CMake 4.5 that we presumably will have in two
> years.
> 
> 
> During code reviews we should systematically delete lines of code that
> are commented out. They can only lead to confusion.
> 
> 
> If we feel that we are dealing with an option to be used sometimes,
> then we should fully configure it as an option that is turned ON/OFF
> from CMake.
> 
> 
> I would suggest that we simply remove the mechanism from the
> CMakeLists.txt file of the Sandbox and when commiting this change
> back to CVS we use a very clear and detailed description of what the
> change means.  It can even be worth to tag both repositories in order
> to signal this significant change. That will make even easier to get
> back to this state if we ever find that necessary.
> 
> 
> 
>   Luis
> 
> 
> 
> --------------------
> Julien Jomier wrote:
>> I agree too.
>> If we can just comment out the mechanism instead of deleting it that 
>> might be useful in case we need it in the future.
>>
>> Julien
>>
>> Andinet Enquobahrie wrote:
>>
>>> Hi Luis,
>>>
>>> I agree with you 100%.
>>>
>>> -Andinet
>>>
>>>>
>>>> Now that we are wrapping up the main developing effort,
>>>> it seems to be a good time for decoupling the Sandbox
>>>> from the main IGSTK library.
>>>>
>>>> We are still using the system that merges IGSTK into
>>>> the Sandbox and test everything combined as if the
>>>> Sandbox were absorbing all the code.
>>>>
>>>> This approach was used during the period we were refactoring
>>>> IGSTK classes and brought them to the Sandbox in order to
>>>> accelerate the process.
>>>>
>>>> The same model doesn't seem to be maintainable for the next
>>>> stage of the toolkit, which is probably a smoother and more
>>>> incremental evolution of the classes.
>>>>
>>>> We could remove the mechanism that copies all the files from
>>>> the main library into a sandbox directory, and simply build
>>>> the Sandbox as a external project based on IGSTK. In this
>>>> more normal scenario there will be no duplication of code
>>>> between the main IGSTK and the Sandbox.
>>>>
>>>>
>>>> Please let us know if you see any drawback in proceeding
>>>> with this clean up.
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>   Thanks
>>>>
>>>>
>>>>      Luis
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> IGSTK-Developers mailing list
>>>> IGSTK-Developers at public.kitware.com
>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> IGSTK-Developers mailing list
>>> IGSTK-Developers at public.kitware.com
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>
>>
>>
>>
> 
> 
>