It looks like you have been having some good thoughts on this - hopefully that will continue to spark some good conversation.
> IMHO recursivity at the file level does not exists
I am not sure this is what you are referring to here, but I would expect any new work to be able to handle cases such as lex/y -> c/h -> .o. In the current diagram that would imply arrows from column A -> C -> A -> C -> E.
On Wed, 29 Jan 2020 at 17:54, Jan Baeyens <jan@xxxxxxxxxx> wrote:
Op 27/01/2020 om 14:47 schreef
Alexander Fedorov:
Hello,
We (with my good friends @ArSysOp) are working on Toolchain
metamodel prototype that should cover the needs of CDT and will be
flexible enough to be applied for sibling areas.
Of course there is a number of EMF usage tricks collected through
all that years that we are going to use during this work. We know
the model-to-text generation technologies from JET to Acceleo, so
we will be able to create whatever we need, not only the default
Java classes.
Great
Currently we are polishing things that were presented for Postgres
community 1 year ago during the "IDE for stored procedures" talk
and discussion. Yes, it may sound curious, but the "toolchain
model" idea with all the "target hardware description" and
"project structure model" appears to be very similar for a lot of
ecosystems.
This is what I would expect. Basically in toolchain land there are
"files" and "tools". There is only a very limited set of
combinations you can have with "files" and "tools".
IMHO recursivity at the file level does not exists and tool sequence
is pretty obvious at the model level. However: correct me if I'm
wrong.
I have been thinking hard about how to model a gcc toolchain and
below is a representation of how I see things now
I haven't yet found a good name for what I called router. It is
absolutely crucial to understand router to understand the model.
All other stuff is pretty obvious
In it's simplest form router will create a list of "input file;
output file" (like "input.cpp" "input.cpp.o"). for each item in
the list tool can add a command which results in "input file;
output file; command" which -in make world- is called a "rule".
A more complicated router may have multiple input files and
multiple output files which means that the router produces a list
of "list of input files; list of output files".
Also the tool can produce more than one command so the output of a
router tool combinations should be a list of "list of input files;
list of output files; ordered list of commands".
The router can also filter input files. For instance in the
example above the output of the "c to object" tool is send to both
the archiver and the linker. It is up to the "collection of
routers" to make sure the files are processed at the right place.
Given a specific file: the model supports all options (archiver;
linker; archiver and linker;none) and assumes the need for coding
to support this construction.
The builder can simply go from left to right processing the
router/tool columns one by one. Asking the routers the "list of
input files; list of output files" checking whether a command
needs to be run and if so ask the command to generate the "ordered
list of commands" to run. Run these and move on to the next.
Note 1 that the router explicitly names the output file(s).
Note 2 when implementing this model it seems logical to have 2
generic routers ("1 on 1" -fi compile- and "all on 1" -fi
archive-) "1 on 1" would need a "name provider" (append .o) and
"all on 1" will need a output file (archive.ar). The model above
needs "custom build" routers next to the generic ones
Note 3 Looking an the linker input files (which can be object
files and archive files) one can argue that the "list of input
files' needs to be a "list of lists of input files". One can also
argue it is up to the tool to "triage the files". I haven't
decided yet what I think is the best.
Note 4: this model assumes there is no order of commands in the
column. It behaves as if all the commands from one column can be
executed at the same time.
Note 5: the model assumes that all actions in a column must have
finished before the next column can be "evaluated/executed". This
allows for "non file based commands" like "pre build actions";
"post build actions" to have their own column like demonstrated
below
Note 6:I understand that note 4 and 5 are a serious constraint
for a more generic modelling tool.
The plan is to share it on GitHub as a set of Ecore metamodels and
then go through several iteration of minor "releases" until we
will find good solution. Then we can have it either as a separate
Eclipse project or as a part of CDT - this may be decided later.
Do you think this will be multi year or multi month project before
we get it into CDT?
Regards,
AF
23.01.2020 23:35, Jonah Graham пишет:
I have no experience with emf modelling so I don't
know it is capable enough. I also have no experience
getting this in java classes. Help will be needed if we
go this way. Learning EMF is now on my todo :-)
Is there some doc from the discussion from Alexander
Federov and William Riley?
P.S. Well, as we started the introduction session ... actually, my
family name is Fedorov, from the Greek "Θεόδωρος " you may know it as
the Latin "Theodor", that means "God-given" :)