Tim,

I just noticed that you aren't generating the plugin header files, when you
generate plugins.  These are the files that are in the platforms/Cross.
directory.  What do we do when a plugin changes it's export interface?
Can't we generate that file, just like we generate the exports?

more below..

From: "Tim Rowledge" <tim at sumeru.stanford.edu>
> "Rob Withers" <rwithers12 at mediaone.net> is widely believed to have
written:
>
>
> > that did it.  I deleted the sqUnixSecurity.c file.
> Nah - got to remove the SecurityPlugin _directory_ since the existence
> of the directory is currently the test. It could reasonably be changed
> to test for the existence of a file in the directory, but I made a
> simplifying assumption.

Ok, that's what I actually did.

> > These two are clearly related, right?   We are computing closures.
> > Currently, you have already filtered unsupported Plugins, before we
select
> > them.  You direct the remaining plugins, from the platforms directory,
to
> > either the vm or the plugins directory in the src.  We would just need
to
> > undo some of those moves, before rewriting.  Undo is better than
> > annihilating the entire src, because we may only want to regenerate part
of
> > the vm/plugins over the previous generation.   The second case, is a
third
> > set of plugins to intersect; those from the platforms directory.
> I'd think adding a check to the methods that write the vm directory and
> the plugins directory would probably do enough; if generating the core
> vm, pre-delete vm/* and if generating external plugins, delete
> plugins/*. Copare with the gymnastincs I have t perform to keep the
> exportsList clean in cases where you for example generate a src tree
> with a few internal plugins and then generate with different internal
> plugins.

I am thinking we may be able to take this one step further for incremental
building.

[exports]
It's the sqNamedPrims.c file that is of interest for the internal plugins.
I noticed that the RiscOS (Acorn?) needs an exports file for each external
plugin as well.   You are scanning the platforms/<os>/plugins to build the
availablePlugins list.  I would like to recommend that we also scan the
<src> directory (both plugins and vm) *and* the sqNamedPrims.h, to build a
generated configuration list.  Then we could generate one plugin at a time,
and rebuild the appropriate exports file, sqNamedPrims.h or external export
file.  Now if we switch one plugin from internal to external, you would have
the generated configuration to rebuild the sqNamedPrims.h, without the moved
plugin's exports, and you can generate the external exports file if you need
to.  Same story if you move a plugin from external to internal or you add a
new plugin.

Thus we have 3 configurations:
    1 - available for the platform
    2 - currently generated from the src
    3 - desired from a config file

We filter what is desired from what is available, like we currently do.
Then we could find the delta from the currently generated, and
delete/move/generate/rewrite only what is needed.  Can we scan the
sqNamedPrims.h file, into sections?

[non-generated files]
To manage the non-generated files, in this scenario, we can find the set of
files that are copied from platforms, for a given plugin, and remove just
those files from the src tree.  My concern here is if the number/names of
files change from the platforms/<os>/plugins directory change between
builds.  As you say, we can just delete that plugin directory from src.  Our
example on moving an internal plugin to external, presents a problem because
we need to delete the plugin files from the vm directory.  Could we have
subdirectories in src/vm, for these internal plugins?  Otherwise, we would
need a manifest of the files for a given internal plugin, _when that plugin
was generated_; the current platforms may be different.

With this capability, we wouldn't need to regenerate the entire vm
directory, but only a specific plugin or the interpreter.

> > For example, your ideas of generating makefiles and projects for the
> > compilers sounds like another homerun.  We could have a Builder
hierarchy,
> > with specifics for each build environment.
> There is already a hierarchy for platform name - see RiscOSVMMaker for
> example. I had to do some moderately tricky gymnastics to make sure you
> get the right class if you change the platform name field!

I was thinking that there could be multiple compiler environments for each
platform, but all of them should be able to work with Makefiles.

Rob