This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/3] manual: Refactor header and standards annotations.


On 11/24/2016 05:17 AM, Joseph Myers wrote:
> On Thu, 24 Nov 2016, Rical Jasan wrote:
> 
>> First, I was going to ask if there was a preference for whether
>> summary.awk should be modified or if a new script was acceptable, and if
>> so which language.  To help make sense of things while working this out
>> I used a Perl script for a scratchpad, which I could clean up for
> 
> Building the manual already requires perl (to generate libm-err.texi) so 
> use of perl is not necessarily a problem.
> 
>> Second, I expect we'll move away from @comment-based annotations to
>> something more explicit/obvious, so I was avoiding enforcing a syntax
>> until we settle on one.  (Not that it's an argument against enforcing
>> now.)  For example, I'm already using new @vitem and @titem macros to
> 
> My view is that when patches cause the manual to meet particular syntax 
> rules that help conversion to another form of annotations, they should 
> also make sure those rules are enforced so we don't regress before the 
> conversion.

I'll whittle down what I've been using to the bare essentials and submit
it with a v2 then.  Practically, changing the @comments to something
else should only result in modifying a couple regexes anyway.

What should I do with summary.awk?  Replace it or stick to syntax
checking only?  I've been calling mine check-stds.pl but it could become
summary.pl.  I suppose replacing summary.awk could always be done later,
too.

Rical


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]