Peter Maydell writes:
> On Tue, 21 Jan 2020 at 11:12, Peter Maydell wrote:
>>
>> On Tue, 21 Jan 2020 at 06:40, Markus Armbruster wrote:
>> > John Snow writes:
>> > > Still, I do want to ask: Are we sure we want to double-down on keeping
>> > > the .hx files around instead of trying to move to
On Tue, 21 Jan 2020 at 11:12, Peter Maydell wrote:
>
> On Tue, 21 Jan 2020 at 06:40, Markus Armbruster wrote:
> > John Snow writes:
> > > Still, I do want to ask: Are we sure we want to double-down on keeping
> > > the .hx files around instead of trying to move to a more generic data
> > >
On Tue, 21 Jan 2020 at 06:40, Markus Armbruster wrote:
> John Snow writes:
> > Still, I do want to ask: Are we sure we want to double-down on keeping
> > the .hx files around instead of trying to move to a more generic data
> > format?
>
> One the one hand, I'd prefer to invest as little as
John Snow writes:
> On 1/17/20 12:30 PM, Peter Maydell wrote:
>> Currently our manual creation includes some .texi files which
>> are autogenerated from .hx files by running scripts/hxtool.
>> .hx files are a simple format, where where a line is either a
>> directive or literal text to be
On 1/17/20 12:30 PM, Peter Maydell wrote:
> Currently our manual creation includes some .texi files which
> are autogenerated from .hx files by running scripts/hxtool.
> .hx files are a simple format, where where a line is either a
> directive or literal text to be output:
>
> HXCOMM
> --
On Fri, Jan 17, 2020 at 05:30:43PM +, Peter Maydell wrote:
> So I think my current view is that we should do the very
> simple "add SRST/ERST directives" to start with:
> * scripts/hxtool needs to recognize them and just ignore
>the text inside them
> * write the hxtool sphinx extension
Currently our manual creation includes some .texi files which
are autogenerated from .hx files by running scripts/hxtool.
.hx files are a simple format, where where a line is either a
directive or literal text to be output:
HXCOMM
-- comment lines, ignored
STEXI/ETEXI
-- mark start/end of
