Re: [Plplot-devel] New way of getting device info from dyndrivers

[Rafael L. <lab...@ps...>]

* Rafael Laboissiere <lab...@ps...> [2003-02-04 22:37]:

>    c) At build time (not configuration time), a small C program dlopen the
>       <driver>.c files, get the symbols described above and write the
>       associated device entries in <driver>.rc (or whichever name).

Just to make things a bit more concrete, here is the design that I have in
mind.  I will take the ps.c driver as an example.  The following global
variables will be defined in the driver source:

    char* DEVICES_ps      = "ps:psc";

    char* DESCRIPTION_ps  = "PostScript File (monochrome)";
    int   TYPE_ps         = plDevType_FileOriented;
    int   SEQNUM_ps       = 29;
    char* SYMTAG_ps       = "psm";
    
    char* DESCRIPTION_psc = "PostScript File (color)";
    int   TYPE_psc        = plDevType_FileOriented;
    int   SEQNUM_psc      = 30;
    char* SYMTAG_psc      = "psc";
    
Of course, these variables should be used in the plD_dispatch_init_*
functions.  In the case of ps.c:

    ps_dispatch_init_helper( pdt,
                             DESCRIPTION_ps, "ps",
                             TYPE_ps, SEQNUM_ps,
                             (plD_init_fp) plD_init_psm );

    ps_dispatch_init_helper( pdt,
                             DESCRIPTION_psc, "psc",
                             TYPE_psc, SEQNUM_psc,
                             (plD_init_fp) plD_init_psc );

This will insure that things are not defined twice in different places (like
with the current DEVICE_INFO_* variable).

The small C program that will generate the <driver>.rc file from the
<driver>.la file, would do: (1) dlopen the module; (2) get the DEVICES_*
symbol and parse its device components (in the ps.c exemple, that would be
"ps" and "psc"); (3) for each one of the devices found, get the symbols
DESCRIPTION_<dev>, TYPE_<dev>, SEQNUM_<dev>, and SYMTAG_<dev>; (4) create
the temp file that is parsed by Geoff's code. (This could be improved along
Joao's suggestion of creating a structure instead of writing the information
in a temp file.)

We have to decide first whether it is not worth abandoning the current
approach and adopting this "cached info" approach above.  There is also
Joao's suggestion for dynamically building the drivers.db, but I am too lazy
to implement that (and I am not sure it is a superior approach).

What do you think?  I accept suggestions for better variable names.

-- 
Rafael