update of jed-extra

[Jörg Sommer]

--mSxgbZZZvrAyzONB
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

G. Milde schrieb am Thu 07. Jul, 11:36 (+0200):
> On  6.07.05, J=F6rg Sommer wrote:
> > G. Milde schrieb am Wed 06. Jul, 12:39 (+0200):
> > > On  5.07.05, J=F6rg Sommer wrote:
> > >=20
> > >   2. a *.sl file must not be preparsed because of preprocessor
> > >      constructs like #if XWINDOWS
> > >      -> add it to a list of not-to-be-preparsed *.sl files
> > >         (make ini has already an exclusion list)
> > >     =20
> > >      Ideally, all such files will be patched to become
> > >      "preparsable". We might make this a requirement for Debian
> > >      packages.
> >=20
> > But the admin can decide, not to preparse the files.=20
>=20
> Preparsing files is a sensible default. If a file poses a problem, the
> admin could set it on the exclusion list in jed.conf.

Do you mean, we should not give the admin the option to preparse or not?
we should do it? Mmmh, are there any disadvantages of preparsing? I think
no?

> > > The "compile" script should
> > >=20
> > >     * delete all *.slc files in site-lib and jed-init.d
> >=20
> > ...that it build before.
>=20
> OK, the algorithm to find related *.slc files from *.sl files is easy,
> isn't it?

You can tell it me? I don't know how to find dfa cache files, whose name
is set inside a SLang file.

> > And I would not preparse the files in jed-init.d, because a admin may
> > make changes there.
>=20
> No problem, outdated slc files are ignored by evalfile().

OK. I didn't know this.

> > > And the following scenarios:
> > >=20
> > >   a) install jed or xjed: call the "compile" script, also compile the
> > >      relevant *.sl files in JED_ROOT/lib/.
> > >       =20
> > >   b) purge jed and xjed: remove all *.slc files.  =20
> >=20
> > This cause problems if you remove one of them. It's tricky to find out =
if
> > the removed package is the last jed/xjed. Otherwise you remove the .slc
> > files for xjed, if you remove only jed.
> >=20
> > There is no need to remove the .slc files upon deinstallation of jed or
> > xjed.
>=20
> I see. So de-installation of jed-common should take care of removing
> *.slc files?

Yes.

> > > The preference in jed-library-path should be
> > >=20
> > >   home-lib, local-lib, package-specific, site-lib, lib
> > >=20
> > > register_libdir() prepends the argument to the path, so jed.conf shou=
ld
> > >=20
> > >   register_libdir(site-lib)
> > >  =20
> > >   % run the scripts in jed-init.d
>       % scripts in jed-init.d might register more libraries
> > >  =20
> > >   register_libdir(local-lib)
> > >   register_libdir(home-lib)
> >=20
> > But if a site admin decide to use a patched version of a file used in
> > jed-init.d is version get not recognized.=20
>=20
> Do you mean: if a file in jed-init.d should use a file in local-lib or
> home-lib instead of site-lib?

Yes.

> Well, this is the prize we have to pay if we want packages to be able
> to register their own libdirs. Otherwise this libdirs would take
> precedence over local-lib and home-lib.

Why? If we register local-lib and home-lib in 30XX.sl it is still
possible to register some mode, they can be overwritten in >30XX.sl

--=20
A red sign on the door of a physics professor: 'If this sign is blue,=20
you're going too fast.'

--mSxgbZZZvrAyzONB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQs7gloZ13Cz2nwVYAQLk3ggAmwFn2KuJMFN06rlMplnJf+2X1/YOBIPS
dHyyD+zEf6AxE9hnGRdbme/Bk1pfUQz/3BtrstmDQUEfh4OqdS7wxWxboCm72U/G
8QNNlIhLdWqJG4Mic4T1g2OFE5Itpkudc+9vbFOtT7gZKGrgDQRKS0WgUtuC/p0O
fI+iJBIaYm19caf42YzHacW9W8w9b6iVEFlodmz93/o1ATWLJK+E45QadW5sPoTJ
O7WZWK5XVSo9uR9vj81QThMo+87Qe2/jFI0YKNeXE74Iaw9y4QTSg46bVRzA/8Lx
TgVCGijIFI97deGtpgCL0DvxCfNBHb+BUWTSbmNBjIHGQbLLl/tQfg==
=mJSu
-----END PGP SIGNATURE-----

--mSxgbZZZvrAyzONB--