Dependency files were not being created for sources that
were only listed in x_SRCS_class variables, because the
code that added those to the x_SRCS var was running after
we had already loaded the dependency files.
The status returned from dbPutField() can now include errors from
the record processing such as a link alarm, so it doesn't mean
what it used to and printing the error might be wrong.
Now we just return the status value.
To Do:
* Test that -l the flag to registerRecordDeviceDriver.pl works
as expected on Windows.
* Modify example template, or create a new template.
* Work out if/how this affects VxWorks, can we generate a munch
file that works the same way as a shared library?
* Test on all arch's, especially Darwin & Windows.
Don't generate code to register record types that have only
been declared, i.e. that have no fields defined in them.
This allows libraries to created which only contain device
support without the record types that they support. The
library must have a DBD file that may declare the record
types (to avoid generating a warning) and also contains any
other device(), variable(), function() and registrar()
entries for software included in the library.
Adds -l flag to the registerRecordDeviceDriver program,
which results in epicsExportSharedSymbols being defined
and shareLib.h being reloaded so the generated output file
can be linked into the library that it is registering.
This aspect has not been tested on Windows DLLs yet.
Record types are the only DBD entries for which the parser
will not accept redefinitions. This change lets it accept
a record type declaration any number of times. However once
a record type declaration has been parsed the full record
type definition cannot be loaded, an error will be raised
if the full definition is seen. The parser will still not
accept a full record type definition more than once either,
any later copies of the record type must be declarations.
If a record type named in a device() entry does not exist when
the device is seen, the DBD parser will now print a warning
and create an empty record type with that name to hold the
device entry information.
This will allow support modules to be built into libraries that
include their own registerRecordDeviceDriver code, which was
apparently possible with 3.14 although not officially supported.
To avoid the warning message, the DBD file can declare each
record type before the device statement that uses it.
A record type declaration looks like this:
recordtype(ao) {}
device(ao, ....)
An IOC will accept and ignore a record type declaration, but it
must have loaded the full record type definition first.
A record type with an empty body is a declaration. The IOC will
accept one of these in a DBD file as long as it has already
loaded the full record type definition.
This will allow device support to provide a DBD file that declares
each record type it uses before giving the related device() entry.
Later commits will explain why.
Michael Davidsaver