[A-A-P-develop] Actions, routes and builders in general

[Bram M. <Br...@mo...>]

A while ago a problem with actions was identified: The supported
filetypes can only be specified statically.  When the action works
differently depending on the system or the currently selected tools,
this can't be specified.

An example is that the "build" action on MS-Windows accepts a ".res"
file.  Thus a ":program" command can accept a "foo.res" file and
directly pass it to the build action.  How to define this, depending on
the current system?

A related issue is that the ":route" command is a bit strange, in that
it defines how to turn one filetype into another and then lists the
names of the actions to be taken.  This is very unusual, no matter what
background you have.

A possible solution would be to support something new and a bit more
flexible: Builders.


The basic idea of a Builder is that it specifies how to build a target
from sources of a certain type.  For example: How to build an object
file from a lex file.  Or how to build a dllobject file from a C++
source file.

Besides the building itself, the Builder can be asked to return the
supported types.  Both for sources and for targets.

Example:

	:program foo : foo.c foo.res foo.l

The ":program" implementation would first find the Builder that produces
an executable program.  From that Builder it obtains the list of file
types it supports for its sources.  Let's call that "linktypes".

":program" then goes through the lists of sources:
- For "foo.c" it finds a Builder that can turn a C file into one of the
  "linktypes".  That is a C compile Builder:  "c" -> "object"
- For "foo.res" it sees that the filetype appears in "linktypes", thus
  nothing needs to be done.
- For "foo.l" a Builder is found that tuns a Lex file into an object
  file.  It uses an intermediate C code file, a separate dependency is
  used for the two steps.

This is very similar to what currently happens with routes and actions,
but the filetypes are not defined statically, they are obtained from the
Builder dynamically.  Thus selecting other tools may cause other
Builders to be selected.

If a Builder consists of multiple steps, such as when a lex file is
turned into C code and then into an object file, this should also be
indicated somehow (only one of the steps may need to be done).

If several Builders are found that could do the work, it should not
matter which one is used.  Perhaps some priority mechanism could be used
to avoid illogical choices.

Since this involves several blocks of code to be associated with a
Builder, an obvious way to implement this would be a Python object or
dictionary.  Most of the Builders would be defined in the tools, which
are Python scripts.  Thus defining Builders with Python sounds like a
good plan.

I think it should be possible to have the :action and :route commands
create a Builder object.  This provides backwards compatibility without
doing everything twice.

Comments?

-- 
hundred-and-one symptoms of being an internet addict:
35. Your husband tells you he's had the beard for 2 months.

 /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\  Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///