D7175: Redesign CMake syntax

[Alex Turbov]

turbov added a comment.


  In https://phabricator.kde.org/D7175#133152, @dhaumann wrote:
  
  > I see seveal issues that imo should be addressed:
  >
  > 1. Please add a test case in autotest/input/ or extend it if one already exists (did you run make test?)
  
  
  no, I don't run tests yet (it is too complicated to build the repo for me nowadays)
  
  > 
  > 
  > 2. How does it work, are we supposed to run this command from time to time manually? If so, then I'd be ok with that.
  
  it work pretty simple:
  
  1. reading YAML (as a Python's `dict`)
  2. prepare (rename keys, & etc) data for renderer
  3. render data (a `dict`) into the Jinja template
  
  as I said the previous generator became unstable -- parsing the output of `cmake --help` is not reliable, so this generator uses "static" YAML file, which should be updated manually
  
  > 
  > 
  > 3. How high is the maintenance burden over time: I understand that this should this, but given we have a yaml file that needs to be maintained manually, I wonder whether we simply move the maintenance from one place to another and additionally introduce complexity (in terms of additional tooling) one first needs to understand before being able to fix things.
  
  the point w/ the current generator: I'm far from sure it "parse" everything correct... moreover, I know exactly that it "parses" `cmake --help` output incorrectly (and one have to fix the generated syntax manually after the generator) and there is really hard to make the generator right cuz the informal/irregular nature of help screens.
  in contrast, the new approach offers a full control over the generated syntax, yeah, by the cost of "manual" maintenance of the YAML file (I tried to make it as simple as possible, and I'm sure it shouldn't be a problem to anyone to add anything to it %)
  Usually, I read CMake's ChangeLog carefully after any new release, spotting new commands/variables/properties/etc and this is the time to update syntax (YAML file)...
  
  > 
  > 
  > 4. The kateversion is back to 2.4 and hard-coded colors are used again. Previously, it was set to 5.0, and used already the newly introduced default styles. I strongly suggest to keep the new default styles - we purposefully changed this some time ago, and I dislike that fact that we go a step back here.
  
  previous cmake.xml do not use anything from modern kate, this syntax works fine w/ KDE4 version of kate. 
  anyway, it would be easy to fix it and remove hardcoded colors anyway...
  
  the hardest part is to realize would this approach be accepted or not

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D7175

To: turbov, dhaumann, #kate, #framework_syntax_hightlighting, vkrause
Cc: cullmann, #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170807/795eaa8b/attachment.html>