sections in configrun-sid

sections in configrun-sid

[Ben Elliston]

This Perl script emits chunks of configuration data to three ordered
sections (named "$first_section", etc).  At the end of the script,
each section is emitted to the configuration file in order.

I am finding this arrangement to be too restrictive.  Currently, I
need to have a "$fourth_section" that makes use of some component
instantiation done late in the third section.

Instead, I think the logic could be simplified by creating a number of
sections, corresponding to the usual arrangement of sid configuration
files:

	$preamble_section
	$load_section
	$new_section
	$set_section
	$connect_section
	$postamble_section

Comments?

Ben

re: sections in configrun-sid

[matthew green]

   
   	$preamble_section
   	$load_section
   	$new_section
   	$set_section
   	$connect_section
   	$postamble_section


sounds good.


one other thing i've been meaning to do is work out how to eliminate
unnecessary shlibs the big list of shlibs in the generated files.
that should improve exectution startup times (at least.)


.mrg.

Re: sections in configrun-sid

[Frank Ch. Eigler]

bje wrote:

: This Perl script emits chunks of configuration data to three ordered
: sections (named "$first_section", etc).  [...]
: I am finding this arrangement to be too restrictive.  Currently, I
: need to have a "$fourth_section" that makes use of some component
: instantiation done late in the third section.

Why are you instantiating components in the third section?

: Instead, I think the logic could be simplified by creating a number of
: sections, corresponding to the usual arrangement of sid configuration
: files:
: 
: 	$preamble_section
: 	$load_section
: 	$new_section
: 	$set_section
: 	$connect_section
: 	$postamble_section

I don't see how this simplifies (program) logic.  It does give better
name to the sections, but perhaps overcodifies them.  (There is no
need to cluster all new's, etc., together, as long as there is a
partial order.)


mrg wrote:

: one other thing i've been meaning to do is work out how to eliminate
: unnecessary shlibs the big list of shlibs in the generated files.

The problem is that the perl script has no easy way of knowing which
component types come from which component libraries.  You can
hard-code the knowledge, analogously to how the "tcl-event-consumer"
component is conditionally instantiated, but I'm not sure that's an
improvement.

: that should improve exectution startup times (at least.)

(Maybe, but only for the dynamically linked case.)


- FChE