Alan Carroll
2018-10-30 16:15:56 UTC
While working on the YAML support for ATS, I ended up making quite a lot of
changes and updates to a set of support utilities which are also in ATS. To
avoid problems while the work was in progress, and because it was suggested
at the summit, I copied those utilities to a stand alone repository[1]. I
have been making PRs on ATS to transfer these changes back to the ATS code
base to prepare for bringing in Canned YAML, the schema support for YAML
work in ATS.
Additionally, most of these utilities are also planned to be provided to
out of tree ATS plugins, as they provide a number of capabilities that
would be handy in plugins, not to mention that if plugins will be using
YAML for configuration, all of this infrastructure will be needed.
Due to some concerns about future ABI issues, it was suggested that all of
this infrastructure be treated the same way as YAMLCPP - that is, dropped
"en masse" in to the ATS code base and compiled separately as a library.
Plugins would then be able to get their own drop of that infrastructure and
link to it, as they would for YAMLCPP, thereby avoiding any ABI issues with
the ATS core.
There are PRs up for this now, if anyone wants to take a look.
[1] https://github.com/solidwallofcode/libswoc
changes and updates to a set of support utilities which are also in ATS. To
avoid problems while the work was in progress, and because it was suggested
at the summit, I copied those utilities to a stand alone repository[1]. I
have been making PRs on ATS to transfer these changes back to the ATS code
base to prepare for bringing in Canned YAML, the schema support for YAML
work in ATS.
Additionally, most of these utilities are also planned to be provided to
out of tree ATS plugins, as they provide a number of capabilities that
would be handy in plugins, not to mention that if plugins will be using
YAML for configuration, all of this infrastructure will be needed.
Due to some concerns about future ABI issues, it was suggested that all of
this infrastructure be treated the same way as YAMLCPP - that is, dropped
"en masse" in to the ATS code base and compiled separately as a library.
Plugins would then be able to get their own drop of that infrastructure and
link to it, as they would for YAMLCPP, thereby avoiding any ABI issues with
the ATS core.
There are PRs up for this now, if anyone wants to take a look.
[1] https://github.com/solidwallofcode/libswoc
--
*Beware the fisherman who's casting out his line in to a dried up riverbed.*
*Oh don't try to tell him 'cause he won't believe. Throw some bread to the
ducks instead.*
*It's easier that way. *- Genesis : Duke : VI 25-28
*Beware the fisherman who's casting out his line in to a dried up riverbed.*
*Oh don't try to tell him 'cause he won't believe. Throw some bread to the
ducks instead.*
*It's easier that way. *- Genesis : Duke : VI 25-28