Re: [Lxr-dev] VHDL support and other stuff

[Robin T. <Rob...@te...>]

Hi Malcom,

Malcolm Box wrote:
> I agree, the current scheme is broken and needs to be replaced.  It
> doesn't even work properly with ctags, since the meaning of the letters
> ctags outputs is not constant across languages.  See the bug at
> http://sourceforge.net/tracker/index.php?func=detail&aid=476695&group_id=27350&atid=390117
> for an example of what's wrong.

I'm not using LXR with C code, but I noticed the mess when reading the man page
for ctags.


> Logically the mappings should be per-language, and ideally Common.pm
> would not depend directly on the installed languages - ie it would not
> hold the list of mappings.  The problem is that the ident script doesn't
> know what language each of the returned identifiers is in to display the
> correct string.
> 
> Probably the best solution is to create another database table that maps
> a numeric id to a string, and then have the language modules store the
> id number where they now store a character.  Then each language module
> can contain the string <-> number mapping, and simply check on
> initalisation that the strings are in the db, adding them if not.

Is'nt it too much hassle to put the strings in db? They can be in the languange
module together with all the other language specific stuff.

In my little head it goes like this:
1) Each identifier has to know what language it is.
2) Language types are possibly ints allocated and defined somewhere in each
language module (or in generic.conf).
3) Each language module defines its own type to string mapping (as ints instead
of chars?).
4) ident looks for the relevant language mapping in the relevant module to
return the string.
5) The indexfile function in each module should insert the type number and the
language number.

This could also make identifiers local to their language, but how should that
be handled when
1) Searching from scratch
2) Displaying the identifier from a link from source (here we know the
language).

I think ident should take an optional language identifier from the URL. This
could be generated from source.

Did I miss out on anything here? I haven't been in every dim lit corner of the
code..
And something in the far dark of my mind says that the changes probably should
be compatible with dbm support.


> Yes, that's fine to include I think.  Is glimpse support working for you
> - I think it's actually broken against a recent version of glimpse?

I found a glimpse RPM version 4.12.5 from somewhere and it runs fine with the
path fix.


> I think it will be OK to add a C module to the distribution, provided it
> comes with some reasonable way to build it.  My guess (correct me if I'm
> wrong) would be that the parser is pretty much vanilla C with no
> platform dependancies, so it should be easy to make build.  I would
> suggest creating a lib/LXR/Lang/VHDL subdir to keep the source and build
> system in.  Then those that want VHDL support can build it, and those
> that don't can just comment out the config in lxr.conf that maps files
> to VHDL (and in fact won't ever see a problem unless they have files
> that look like VHDL).

I agree, but... The code skeleton has the following license (the files are from
'93):
 * This file is intended not to be used for commercial purposes
 * without permission of the University of Twente and permission
 * of the University of Dortmund

I'm going to contact the source to see if it can be GPL'ed or whatever.
If you know any other GPL'ed VHDL parser that's just the yacc skeleton with
grammar, I could hack that up instead. 

The parser code btw, required quite many hacks. It was in a very old lex
dialect and gave some trouble with both flex and gcc. It would probably need
some more cleaming to run on non gcc platforms. Again, the largest problem is
probably the license.

Regards,

Robin.

-- 
ASIC Design Engineer
Tellabs Denmark A/S