EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  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  Index 1994  1995  <19961997  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 
<== Date ==> <== Thread ==>

Subject: Re: macro substitution
From: [email protected] (William Lupton)
To: [email protected]
Date: Tue, 13 Feb 96 08:46:01 HST
Marty,

> 
> c) long macRead ( MAC_HANDLE  handle, char *name, long maxlen, char *value );
> 
> This is picky but I think the maxlen argument should follow value.

OK. The same for macSubst(). I know there's always a quandary between making
things like strncmp() or strncpy() and the more traditional "input, modified,
returned" convention.

> d) long macWrite( MAC_HANDLE  handle, char *name, char *value );
> 
> This is a general comment.
> What are rules for allocating storage?
> How does macClose know what it can free?
> As an example should maxWrite alloc and copy value or just copy
> pointer value? If it just copies pointer value who frees storage for value?

As specified, macRead() and macSubst() fill in a caller-supplied string, hence
the maxlen arguments. I would be quite happy to change this to have them
allocate strings which the caller should free.

Because of the greater complexity of the returned value from macConvert() I
(as did Jim) already had it allocating its returned string. So we could change
the specs so that all returned strings are allocated and must be freed by the
caller?

macClose() would free just what it had allocated internally and _not_ passed
back as results of routines such as macRead(). The caller would always be
responsible for freeing such strings (or else one could say just the opposite,
but I think most programmers expect to be responsible for freeing things which
are returned via "GOOP **" arguments).

> 2. Macro substitution tool
> --------------------------
>
>    I also favor going with make syntax rather than shell syntax. I would
>    also imagine that supporting $(fred:%=%.o) type pattern operators might
>    be useful in the future, and these can be modeled on make too. Similarly
>    other built-in macros.
>
> Why are we defining this tool? For what will it be used?
> If such a tool is defined I would vote for shell rather than make syntax.
> I think we made a mistake using $() instead of ${} for macros (too late now).
> I am very wary about such a tool for use on vxWorks.

I don't see this tool being used on vxWorks (at least I can't see any applic-
ations right now). I see it being used to implement various make rules. The
ones that I see right now are:

a) processing a set of subsystem .alhConfig files into a single system-wide
   one which has each sub-file (typically) as a sub-tree (we have been using
   the C preprocessor for this but this is not completely satisfactory; of
   course if alh supported macro and file inclusion directly, the make-time
   concatenation would not be necessary)

b) processing vxWorks startup files (UAE has a %.vws -> % rule) to substitute
   macros for target architectures, EPICS versions, application versions etc
   (currently this is done via a sed script which does not allow extra macros
   to be defined)

As for $() and ${} and shells versus make, I would say that you have to make
more use of macros in Makefiles than in shell scripts in order successfully
to build EPICS software, so it doesn't seem ridiculous to take the lead from
make. I know that GNU bash allows nested macro references; does it also use the
${} syntax (I expect so)?

> Discussion re dbLoadDatabase() etc omitted...

I think that all I should be concerned with here is whether the proposed
macro facility provides the necessary facilities, and you conclude that it
probably does, so that is good.

As for performance, it seems to me that this is again largely outside the
control of the macro facility (assuming that it is not implemented in a
ridiculous fashion). The support for the "file" statement which acts as an
implied for loop would avoid unnecessary file opens and closes since a single
file could be kept open for all its multiple inclusions (but I think that we
are agreed that vxWorks applications would normally be using macLib rather
than mactool).


Navigate by Date:
Prev: Re: macro substitution (forwarded from Marty) William Lupton
Next: Allen Bradley Driver Marty Kraimer
Index: 1994  1995  <19961997  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: macro substitution William Lupton
Next: Re: macro substitution Jim B. Kowalkowski
Index: 1994  1995  <19961997  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 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·