my idea is not to put .oct files an one fixed place; just making it possible to install .oct files at one place and .m files at another one.
Reason: .oct files are architecture (x86, AMD64, ...) specific, while .m files can be shared among different architectures.
I have a simple patch for most files with the exception of oset.m and ohold.m. The problem with these two: the 'install' command does not preserve symbolic links, so we end up with a copy of set.m and hold.m, respectively.
Do you still target Octave 2.1 with Octplot? Otherwise, we could use Octave's 2.9 'autoload' feature.
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The .m files should be somewhere under /usr/share and not under /usr/lib. Instead of having everything installed under $OCTPLOT_LIB, there should be a Makefile variable e.g $OCTPLOT_MDIR that can be configured by the packager.
Tormod
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't mean to change the location of the .oct files, but the .m files should be moved.
Currently: all .oct and all.m file go into the same directory (with the exception of toggle_octplot.m).
Future: all .oct files go into one directory (this can stay as it currently is).
All .m files go into another directory.
One way to achieve this is to put all .m files under "mpath_DATA" in Makefile.am.
Totally independent of the above:
oset.m and ohold.m should be symlinks to set.m and hold.m, respectively. However, the current setup installs copies of these files, saved as oset.m and ohold.m. There is not much one can do about it, short of changing the installation system (octave-forge had similar problems, see http://octave.cvs.sourceforge.net/octave/octave-forge/octinst.sh.in?view=markup&pathrev=R2006-07-09
search for "Grr")
This is a limitation of the "install" command and not a bug in the package.
Now, if you would say: "Octplot is meant for Octave 2.9", we could use the "autoload" feature, that was introduced there, eliminating the use of symlinks completely.
Anyway, I will come up with a patch in short time.
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
octave-forge uses /usr/share/octave/site/m/octave-forge for m-files and /usr/lib/octave/site/oct for oct-files, at least in the Debian/Ubuntu packages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree that fonts should be in an architecture independent location.
Actually most Free systems should have these fonts installed already, as they are one of the few Free quality TT fonts available (probably ghostscript has them). However, I was too lazy to check for their existence.
Anyway, Thomas, do you have any ideas ?
Shai
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, the patch I submitted has a --with-fontpath option, so it's already possible to put the fonts wherever you want.
I thought about using the 'gsfonts' package in Debian instead of the fonts shipped with octplot, but there are two problems with it:
1. The font files differ. I don't know which version is newer/better.
2. More important: size. The fonts in octplot have around 800kb, whereas the gsfonts package has about 6MB.
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
is it possible to handle all .m files the way toggle_octplot.m is handled? That is, they go under a share/ directory and not under lib/?
Thomas
Thomas,
I think I did this beacuse this is octave-forge does and I just copied. Do you have any suggestion on where to put the oct files?
Shai
Hi Shai,
my idea is not to put .oct files an one fixed place; just making it possible to install .oct files at one place and .m files at another one.
Reason: .oct files are architecture (x86, AMD64, ...) specific, while .m files can be shared among different architectures.
I have a simple patch for most files with the exception of oset.m and ohold.m. The problem with these two: the 'install' command does not preserve symbolic links, so we end up with a copy of set.m and hold.m, respectively.
Do you still target Octave 2.1 with Octplot? Otherwise, we could use Octave's 2.9 'autoload' feature.
Thomas
Thomas,
I'm not sure what you mean -- the oct file are under an architecture dependant library.
Maybe you can give an example of what is currently done, and what you think should be done
Shai
The .m files should be somewhere under /usr/share and not under /usr/lib. Instead of having everything installed under $OCTPLOT_LIB, there should be a Makefile variable e.g $OCTPLOT_MDIR that can be configured by the packager.
Tormod
Hi Shai,
I don't mean to change the location of the .oct files, but the .m files should be moved.
Currently: all .oct and all.m file go into the same directory (with the exception of toggle_octplot.m).
Future: all .oct files go into one directory (this can stay as it currently is).
All .m files go into another directory.
One way to achieve this is to put all .m files under "mpath_DATA" in Makefile.am.
Totally independent of the above:
oset.m and ohold.m should be symlinks to set.m and hold.m, respectively. However, the current setup installs copies of these files, saved as oset.m and ohold.m. There is not much one can do about it, short of changing the installation system (octave-forge had similar problems, see
http://octave.cvs.sourceforge.net/octave/octave-forge/octinst.sh.in?view=markup&pathrev=R2006-07-09
search for "Grr")
This is a limitation of the "install" command and not a bug in the package.
Now, if you would say: "Octplot is meant for Octave 2.9", we could use the "autoload" feature, that was introduced there, eliminating the use of symlinks completely.
Anyway, I will come up with a patch in short time.
Thomas
I'm not yet ready to move octplot to octave 2.9 branch. I would like to wait first, to see if it (octave 2.9) agrees with cygwin
Shai
Hi,
this took longer than expected, but I've submitted a patch
http://sourceforge.net/tracker/index.php?func=detail&aid=1584495&group_id=86268&atid=579016
I don't consider this the final one, but it's easier for people to comment if there is some code.
Thanks
Thomas
Thanks for this patch
I looked it over and it looks OK to me. I will wait a few days to see if anyone has any comments and than I think I will apply it
Thanks again
Shai
octave-forge uses /usr/share/octave/site/m/octave-forge for m-files and /usr/lib/octave/site/oct for oct-files, at least in the Debian/Ubuntu packages.
Also the fonts files should be moved to an architecture-independent location.
I agree that fonts should be in an architecture independent location.
Actually most Free systems should have these fonts installed already, as they are one of the few Free quality TT fonts available (probably ghostscript has them). However, I was too lazy to check for their existence.
Anyway, Thomas, do you have any ideas ?
Shai
Well, the patch I submitted has a --with-fontpath option, so it's already possible to put the fonts wherever you want.
I thought about using the 'gsfonts' package in Debian instead of the fonts shipped with octplot, but there are two problems with it:
1. The font files differ. I don't know which version is newer/better.
2. More important: size. The fonts in octplot have around 800kb, whereas the gsfonts package has about 6MB.
Thomas