[IGSTK-Developers] Sandbox decoupling

[Luis Ibanez]

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
>>
> 
> 
>