update of jed-extra
G. Milde
g.milde@web.de
Mon, 11 Jul 2005 10:16:06 +0200
On 8.07.05, Jörg Sommer wrote:
> G. Milde schrieb am Thu 07. Jul, 11:36 (+0200):
> > On 6.07.05, Jörg Sommer wrote:
> > > G. Milde schrieb am Wed 06. Jul, 12:39 (+0200):
> >
> > 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?
No other than a custom variable for an exclusion list. Checked in
byte_compile_libdir(). Used for the problematic cases mentioned below.
> we should do it? Mmmh, are there any disadvantages of preparsing?
You loose the ability to do runtime decisions with preprocessor
directives like #ifdef or #ifexists, e.g.
#ifnexists foo
define foo() {message("foo");}
#endif
or
#ifdef XWINDOWS
require ("cuamouse"); % CUA consistent mouse behaviour
set_color_scheme ("yellow");
#else
set_color_scheme ("light-terminal-default");
#endif
(I moved the latter example to my .jedrc which is not preparsed by
default.)
> > > > The "compile" script should
> > > > * delete all *.slc files in site-lib and jed-init.d
> > > ...that it build before.
> > OK, the algorithm to find related *.slc files from *.sl files is easy,
> > isn't it?
>
> You can tell it me?
define find_slc_path(path)
{
return path + "c";
}
> I don't know how to find dfa cache files, whose name
> is set inside a SLang file.
This is a different problem, you could only grep in the SLang files.
However, both, slc files and dfa files are actually just "secondary"
(temporary) files. A purist would place them under /var/. Is there a way
to tell dpkg that *.dfa files are of no special importance and can be
savely removed when removing the containign dir?
> > I see. So de-installation of jed-common should take care of removing
> > *.slc files?
> Yes.
Agreed.
> > > > jed.conf should
> > > >
> > > > register_libdir(site-lib);
> > > > % run the scripts in jed-init.d (might register more libraries)
> > > > register_libdir(home-lib, local-lib);
> > >
> > > But if a site admin decide to use a patched version of a file used in
> > > jed-init.d is version get not recognized.
> > 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
With this scheme, we had in jed-init.d
00XX.sl % files that might register package libraries
...
29XX.sl
30home-lib.sl % register local-lib and home-lib
31XX.sl % files that can easily use modes from local-lib and
... % home-lib but not register package libraries
99XX.sl
I do not see the need for files >30XX.sl. Debian packages should not need
to use home-lib or local-lib. The sysadmin can put the configuration in
jed.conf instead.
Günter
--
G.Milde web.de