|
There's a serious problem with the design so far, where symbols are used
for attribute names (intensity, strobe, colour etc), and also for
attribute values (on, off, random etc). There's no way for 'at' to
tell the difference between the two. For example, this form is
ambiguous: (at myfixture 'strobe 'on)
This commit introduces a new class, <starlet-attribute>, to replace the
use of symbols here. The attributes are enumerated in (starlet attributes),
and new ones can be added later. The attribute objects remember their
'canonical' names, to allow states to be printed.
Apart from solving the ambiguity problem, this has two further
advantages. First, attribute names no longer need to be quoted
everywhere. Second, multiple names can be used to refer to the same
attribute. For example: (define color colour).
|
|
Unfortunately, I can't see any practical way, using the build system, to
compile the .scm files into .scm.go files in the system 'site-ccache'
directory:
Using generator objects, the produced objects are explicitly only
allowed to be used as input for targets, not to be installed themselves.
Using individual custom targets, there would have to be numerous
repetitions of the entire kerfuffle required to invoke guild. One
target can only process one file.
A single custom target running a script which compiles everything -
might work, but even that is tricky to get right. And it's completely
unportable.
For all the above cases, there is still no guarantee that the compiled
objects would be installed after the sources, as necessary to prevent
spurious recompilation. It doesn't even seem that much easier to do
this with Autotools, supposedly the recommended build system for this.
Trying to make this work, I've already spent more time than will likely
ever be saved by pre-compiling the sources. Let's just install the
source files and let Guile automatically compile them into the user
cache location.
|
