> From [email protected] Fri Jun 9 13:58 CDT 1995
> Date: Fri, 9 Jun 95 08:57:38 HST
> From: [email protected] (William Lupton)
> To: [email protected]
> Subject: Re: application directories and CVS, GNU make etc
> Content-Type> : > text>
> Content-Length: 3246
p-level directory.
>
> I am very interested in your plans to do away with default.dctsdr
> (which I moved to a "data" installation directory because I couldn't
> bring myself to live with having installed files at the top-level). This
> would greatly simplify my plans for catting cat_ascii directories and
> the suchlike. Is there any way in which we can help here?
>
Here are the main goals of this project.
1) Allow each database and ioc to use only the record types, device support,
and drivers it actually needs. Thus even if applications and iocs share
a common development tree each application/ioc can still use only
the support it needs.
2) Change dbStaticLib and iocCore so that it is possible to incrementally
add record types, device support, driver support, and record instances.
This is being done so that it will be possible to have on line add and
delete and on line modification of links. Note that these features
are not part of initial project but are necessary to add these features
later.
3) Get rid of build utilities. Database Conf tools will get all info via
ascii files. IOC will get info via combination of ascii files and code
generated by same compiler that compiles other ioc code. This should
remove all architecture dependent problems related to the fact that
default.dctsdr is a binary file.
I can see how to do all of the above. I have already written some utilities that
accept old default.dctsdr files and generate the new ascii format files.
I have also started modifying dbStaticLib. I see no major problems in meeting
all of the above goals. In a few weeks there should be a document explaining
what is being proposed (Sorry. I have been having fun writing some code.
At least part of it was necessary so that I could convince myself that there
were no traps. At least that is my excuse for writing code before making
doc widely available)
In order to make this project really successful packaging is very important.
By this I mean "What will the users see". All Application Source/Release
environments will have to be modified. Here is an initial list of some
goals.
1) All record support, device support, and driver support should be unbundled.
Thus users should only obtain the support they actually use. This applys
to both database configuration tools and to what is loaded into iocs.
2) Users should easily be able to define the support they want. Ideally they
would have a single file that looks something like the following:
include "aiRecord.ascii"
include "calcRecord.ascii"
...
include "abDriver.ascii"
...
If we can get to this point we should even be able to easily implement
a tcl/tk based GUI interface for users to create the above file.
3) Must stay compatible with the database config tools users are currently
using or intend to use. Note that minimal changes will be made to the
existing static database access API (described in App Dev Guide). Thus if
database config tools use that interface they can easily be changed to
support new version of dbStaticLib.c.
Some questions.
How do we get Source/Release to support this?
What should we do to base?
How do users add private record/device/driver support?
How do we handle makefiles so that they only build/link what is necessary?
A lot of thought and help is needed to answer these questions.
> I think that in the short term, Nick and I will continue to iterate
> and will document what we have done. Another major challenge of course
> is to handle the hooks to local conventions in a very neutral way. I
> tried to do that with my EPICS_APPLIC_INSTALL, EPICS_APPLIC_VERSION and
> EPICS_APPLIC_EXTERNAL variables.
>
Again let me mention that a lot of thought and discussion went into the
App Source/Release system at APS and that Johnny Tang looked at it hard before
making changes. Note that the currect version does support the new CONFIG
environment. It does not yet, however, support CVS. Thus it is no longer
necessary (and discouraged) to use imake. It is still necessary to use sccs.
Remember that an important goal should be to place EVERY user editable file
under S/R control.
> If we are to move towards a single system then we all potentially have
> to compromise, so it would be useful to know what the major sticking
> points might be from your point of view. What are the sacred cows?
>
This is a hard question. I dont think I can give a simple answer.
Marty Kraimer
- Navigate by Date:
- Prev:
Real-Time Software Engineer Position Rick McGonegal
- Next:
Database Lite Bob Dalesio
- Index:
1994
<1995>
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: application directories and CVS, GNU make etc William Lupton
- Next:
Re: application directories and CVS, GNU make etc Rozelle Wright
- Index:
1994
<1995>
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|