[vtk-developers] vtk_common dashboard script

David Cole dlrdave at aol.com
Tue May 21 10:34:09 EDT 2013


-----Original Message-----
From: Marcus D. Hanwell <marcus.hanwell at kitware.com>
To: Brad King <brad.king at kitware.com>
Cc: David Cole <dlrdave at aol.com>; VTK Developers 
<vtk-developers at vtk.org>
Sent: Tue, May 21, 2013 9:35 am
Subject: Re: [vtk-developers] vtk_common dashboard script


On Mon, May 20, 2013 at 3:44 PM, Brad King <brad.king at kitware.com> 
wrote:
> On 05/20/2013 03:32 PM, David Cole wrote:
>> Is there any reason not to simply use a reasonable default value for
>> ExternalData_OBJECT_STORES directly in the VTK CMakeLists file?
>>
>> Then no dashboard scripts would have to be adjusted. You could just
>> know that it's in the default location unless otherwise specified.
>> Perhaps it could be:
>>
>> (1) parallel to the build tree
>> (2) under the HOME or USERPROFILE env var directory
>>
>> get_filename_component and if(EXISTS could be used to place things 
in a
>> reasonable default location without any script editing...
>>
>> Any reason not to do it that way?
>
> I don't want to write content outside the source and build trees
> without explicit local configuration.  A common expectation among
> users is that deleting a source and build tree is all that is
> needed to wipe out all record of a project having been built.

The expectation is also that data is persistent, if we don't change
the default perhaps we can at least add a warning at configure time to
advise that data will be downloaded multiple times (the default is
each build tree?) I would love to see a default parallel to the source
tree, like VTKExternalData or something, but it seems like you are
strongly opposed to that.

Thanks,

Marcus



Additionally, in favor of a parallel sibling directory to the source 
tree... I think of this as a replacement for a VTKData checkout, which 
has traditionally always been recommended to be a parallel sibling 
directory.

Wasn't VTK and VTKData in the same parent directory the recommended 
structure? And didn't the common script do a checkout of VTKData such 
that they ended up that way?

Just because we're using a new technique here doesn't mean we have to 
change something like that.

Seems completely reasonable to me to say: the default is *here*, and 
it's a cache setting... if you want it somewhere else, change the cache 
setting.

What I don't want is *this*:
to have multiple build trees of VTK going on my laptop, and to 
*accidentally* get multiple copies of VTKData and VTKLargeData just 
because I left something at its default value.

I don't know about all of you, but on my laptop, drive space is still 
at a premium. (I realize I am inviting people to make fun of me here, 
so have at it. ;-)


David C.





More information about the vtk-developers mailing list