Depends on D4860
Adding basic rust to the backup service.
Differential D4861
[services] Backup - Add Rust • karol on Aug 17 2022, 3:54 AM. Authored by Tags None Referenced Files
Details
Diff Detail
Event TimelineComment Actions Weird that some cmake rules don't allow upper case letters for variable names (which is pretty standard I'd say), the regex is: [a-z][a-z0-9_]+ @atul should we fix this? I'm publishing this because I don't think this is an error. Comment Actions Please take a look at D4805, the diff is to add corrosion_cxx.cmake with the modifications for our needs instead of just copy pasting the rusty_cmake cmake file:
The main problem that will appear is: that when using the original cmake file from rusty you should find somehow the target architecture and pass it to it. Comment Actions Ok, once your diff is landed, I'm going to rebase to it and take your version removing mine, no problem. How about the rest of this diff? Comment Actions I'm not sure if there is a good reason for this (CMake can have strange requirements...) or maybe it is just a "style guide" thing for CMake. That said, does the variable type really matter? It doesn't seem like a great use of people's time to figure out a way to revise this... I think @jon is more likely to know the answer here than @atul, but my general suggestion is just to use lowercase variable names to appease the CI...
Comment Actions
It's about names, not types. I think we should resolve this. The same checks seem to run on the CMakelist.txts and *.cmake files but still with the corrosion.cmake we get errors and with the rest of the files we do not even though there seem to be very similar definitions in both files.
So I perceive this as an invalid CI action (false positive).
That doesn't solve anything. I think we should either turn off this rule or get it fixed. Comment Actions Sorry, I meant variable name not type. If the variable name is your decision then I think we can just follow CMake Lint's requirements. If the variable name is decided by somebody else, then we can disable the rule like we do here. Curious for @jon's perspective on this one too. Comment Actions Sorry, but it seems to me like you didn't really address what I said:
How about this? I do not think that CI should behave like this, it's not logical to me, and would be cool to find out what exactly is going on here. I will disable the rule but I think it's more like a dirty workaround than a reasonable solution.
Comment Actions
Comment Actions
There's no rhyme or reason with CMake naming conventions. Every ecosystem seems to have created their own convention over CMake's history. It's just that cmake-lint establishes some conventions which make it unambiguous about variable usage. Why it errors in some usages, but not other usages; I have no idea. Comment Actions
I think that's the real problem. |