Re: [OctDev] main ported to the package system

[H. <so...@ha...>]

Okay, I think I understand! I never thought that it would be that
important to have stuff like this in the package manager. I just
figured, that we would have some scripts to aid the package developer.

You suggested that the package developer creates a file that contains
lines like this
	gf glu
which is converted into a file that contains
	autoload ("glu", which ("gf"));
Personaly, I don't see the great win about this. Why not simply let the
developer create the PKG_ADD file? We can provide scripts that can
extract
	## PKG_ADD: XXX
comments from .m and .cc files to aid the developer.

I don't see an easy way of integrating things like this in the package
manager, simply because I don't think it is the job of the package
manager, but the job of the package developer. I'll be happy to
implement changes in the package manager, but I'll need to be told what
to implement :-)

S=C3=B8ren

man, 21 08 2006 kl. 17:10 +0200, skrev David Bateman:
> S=C3=B8ren Hauberg wrote:
>=20
> >I've copied the admin directories to the packages that needed the
> >octlink.sh script. If I forgot to copy it into a package that actually
> >needs the script, then I've made a mistake. Which packages are giving
> >you problems because octlink.sh is missing?
> >
> >I've not been involved in octave long enough to actually know what the=
se
> >scripts does. But from what you are saying, I get the impression that
> >octlink.sh needs to be removed from the individual packages and replac=
ed
> >by PKG_ADD files.
> > =20
> >
>=20
> octlink.sh was a hack that allowed support of both symbolic links and
> the use of the octave autoload function on systems that supportted it.
> Version of octave later than 2.9.4 all support autoload and so
> octlink.sh is no longer needed as such as what is done in this script
> should be done for all symbolic links. However, with the way the pkg
> build system seems to work this means it needs to be done on a package
> by package basis (Soren comments)
>=20
> This stuff hooks into the admin/mkpkgadd script. Again it doesn't seem
> obvious to me how we can make mkpkgadd and octlink part of pkg.m rather
> than the individual packages. Searching the *.m and *.cc files for
> PKG_ADD commands is easy enough, but the treatment of the symbolic link=
s
> needs to be done on a package by package basis.
>=20
> Perhaps we can make a pkg/src/symlinks and pkg/inst/symlinks file in th=
e
> package manager, that includes pairs like
>=20
> gf glu
> gf greal
>=20
> etc, which repesent "ln -s gf.oct glu.oct". The pkg.m script can then
> convert these to
>=20
> autoload ("glu", which ("gf"));
> autoload ("greal", which ("gf"));
>=20
> in the PKG_ADD file. This of course requires a small modification the
> pkg.m. So Soren your thoughts on this are necessary.. I'll try to
> propose something since this is blocking my porting of the
> communications toolbox.
>=20
> D.
>=20
> >S=C3=B8ren
> >
> >man, 21 08 2006 kl. 16:22 +0200, skrev David Bateman:
> > =20
> >
> >>Ok, another nasty problem is that the admin/octlink.sh script is not
> >>copied to the pkg src/ directories. Perhaps as teh package manager is
> >>only in versions of octave which have the autoload function, this can
> >>all be simplified, as only the .octlink fashion of dealing with the
> >>files needs to be treated. That is we should probably generate the
> >>appropriate PKD_ADD file directly rather than use octlink.sh.. This
> >>problem occurs wherecer symbolic links are used in octave-forge. Its
> >>vital that autoload is used if possible to allow significant reductio=
n
> >>in binary size especially for cygwin and mingw platforms...
> >>
> >>I'll work out a solution for the communications toolbox and propose i=
t.
> >>
> >>D.
> >>
> >>
> >>   =20
> >>
> >
> >
> >
> > =20
> >
>=20
>=20