On 25 Jul 2009, at 04:50, Søren Hauberg wrote:
> fre, 24 07 2009 kl. 22:20 +0200, skrev Thomas Weber:
>>> I wouldn't object to having a 'inst/data' directory, but is that
>>> easier
>>> to locate from within the code?
>>
>> I find
>> fopen('data/filename');
>> simpler than
>> fopen('../data/filename');
>>
>> Okay, I admit it: a weak argument :)
>
> I must admit that I buy your argument :-)
>
> That being said, can you actually do that? Doesn't that require that
> your current working directory contains the m-file in question?
>
> Say, you want to read the data as part of a test of 'nanmedian', would
> you then have to write something like
>
> directory = fileparts (which ("nanmedian"));
> datafile = fullfile (directory, "data", "filename");
>
> ?
>
> Søren
Thinking a bit more about it,
one argument in favour of having data in "inst/data" is that it
doesn't require any change to pkg.m as any subdirectory of "inst" will
be copied to the package installation location so to
make this change only the documentation would need to be changed...
On the other hand, the manual entry for the package format currently
states:
...
@item package/inst
An optional directory containing any files that are directly installed
by the package. Typically this will include any @code{m}-files.
...
this seems to imply that "inst" is not expected to contain only m-file
code but "any files that are directly installed" i.e. files that do
not need to be compiled before installation. it seems to me that this
includes data files! so my question is:
do we really need to force developers to have a separate directory for
data? what is wrong with the currently documented approach of having
all m-files and data files put into "inst"?
BTW if a particular developer likes to have his/her code/data
subdivided into subdirectories (I usaually do) this is already
possible with the current setup...
c.
------------------------------------------------------------------------------
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
