I’ve decided it’s about time that I learn how to use Alire. However, I’ve run into a question/problem regarding the default style Alire imposes on the programs built using it.
I understand the value in having a community-wide style. I don’t love some of the options in Alire’s default style, but I could get used to them for the sake of consistency across the community. However, one option in particular is going to be hard for me to swallow: the 80 character limit on line length.
The default style specifies the -gnatym switch to impose line length checks, but without a -gnatyM switch to specify the line length. This results in the default length of 80. While that might be a reasonable default for -gnatym, it looks absurdly narrow on today’s high resolution monitors (including on my 13.8" laptop). Also for Ada, a language where the culture encourages long, descriptive names that are fully qualified, it causes a lot of awkward (and unnecessary?) reformatting of “long” lines.
I decided to tweak Alire’s default style by adding -gnatyM96 to relax the line length requirement to 96 characters. It’s a modest change, but it makes a big difference in usability, at least in my view.
I discovered I can do this in alire.toml by adding a build-switches table like this:
[build-switches]
"*".style_checks = ["-gnatyM96"]
This works, but it has the effect of replacing the default style rather than augmenting it. That’s not my intent. It appears that to get the effect I want, I would need to explicitly reproduce all the style options Alire uses by default, aside from the line length business, of course. Unfortunately, the Alire documentation doesn’t appear to specify the default style options. I was able to see the list by inspecting the GPR file generated by Alire, and it’s moderately lengthily. Manually copying it feels awkward and error prone, making me wonder if there is a better way.
This leads to two questions:
Is the Ada open source community really serious about the 80 character line length limit? I didn’t inspect any other crates to see how strictly it is being followed, but I have to believe I’m not the first person to complain about it.
Is there a way to add my -gnatyM96 switch to the default switches without having to copy all the defaults by hand?
Okay, I see. It looks like you created the alire.toml using the --no-skel option and then provided your own project file.
I did the simplest thing I could think of, which was to let Alire generate the project files from scratch. So, for example, I don’t have a project-files option in my alire.toml.
But the important thing here is that I’m not being a bad citizen of the community by wanting to change the line length limit to something greater than 80!
Thanks! That’s good to know. I wasn’t sure how to adjust the switches coming in from the configuration project file.
I see that you are also turning off -gnatyB. I was trying to decide how I felt about that one. Using -gnatyB and requiring and then and or else in all but the most trivial cases, seems like an admission that Ada got this wrong and the short circuit evaluation done in C and C++ is actually better. Do we want to admit that?
I do think that Ada got it wrong by not defaulting to lazy evaluation, but that’s difficult to change now, so we’re stuck with it.
I don’t think that a style warning is appropriate to inform you that the default behavior is probably not what you want. But I’ve also just grown accustomed to typing ‘and then’ ‘or else’ everywhere, so I don’t bother turning off that warning anymore.
In practice, it doesn’t really matter. GCC is gonna optimize out the extra evaluation most of the time anyway.
It is 72, sir! The positions 73…80 are reserved for the punched card number!
72 is a perfect number. I usually split the GPS windows vertically into 3-4. You need at least 3:
Test
The package specification
The package body
Being one of few use-clause fans I never use fully qualified names.
IMHO(*), “and then” and “or else” should only be used when a specific order of evaluation is required by the logic of the program, for example “if ptr /= null and then ptr.boolean_component then …”.
In all other cases, let the compiler determine the order of evaluation of the subexpressions.
This is kind if similar to not specifying the order of evaluation of the arguments in function or procedure calls either. Only when really required one introduces temporary variables to force a specific order.
(*) Not just “my opinion”. We used this approach in several big industrial projects I worked on.
I used to do similar but have recently gone back to the default. I use this in the .gpr for the labguage server though and mostly use named parameters.
package Pretty_Printer is
for Default_Switches ("ada") use ("--call-threshold=1", "--par-threshold=1", "--vertical-enum-types", "--vertical-named-aggregates", "-W8", "-c5", "-c4");
end Pretty_Printer;
I’ll be honest. I don’t think Alires configuration is currently easy to utilise by users. I would call it time consuming. Commented out default options in the style of sshd_config would be better in my opinion. Backed by a man page or man page style web page that concentrates solely on the possible config options would be ideal.
I am also bothered by this default.
I used to changed it to M100, but now I remove it completely.
In some situation, cutting the line is a nuisance for readability (for example large table initialization).
I guess that most of us no more print sources, so I don’t see any benefit in such a constraint.
I agree with that.
And because it was not easy to change some of the defaults, I ended removing all references to Alire default in my gpr, except for obj directories.
If there is an handy way, or some cookbook, I’m more than interested!
Speaking as someone who just recently dived in the Alire documentation, I agree that it could be better. The information seems to (mostly) be there, but it also seems haphazardly organized. It was harder for me to figure out how to do things than I felt like it should be.
I don’t know of a simple way as I am still very new to Alire, but I ended up using an aggregate project and pointing alire to that instead of my project. This allowed me to make my gpr project file the main one where all changes/switches were while still allowing me to use the commands from alire like alr --release (but with my switches).
It involved telling the alire.toml file to use that aggregate project instead of my own (but the aggregate project handled all of the linking) and also to put the generated files in a specified folder with that aggregate project. But it means I can freely use either alire or just gprbuilld and both independently work off of the same gpr file (I can even delete alire.toml and the alire folder I created and everything still works as is with gprbuild).
It does mean thought that I am on the hook for starting a project with my own template by hand (copy/paste/rename). I setup my template with project names that would cause the alire ecosystem to fail until I changed them to be correct/consistent. I should probably make myself a tool to streamline using my template.
NOTE: There could be easier ways, I am new to Alire, but I wanted alr --release and such to all work with my projects seamlessly without using the default switches and in a way that I could also use gprbuild without it knowing alire existed (if desired).
The Ada Language Server depends now on GNATformat which also looks like the way that is going. From Simon it ignores Pretty_Printer and uses package Format.
At the moment ALS allows either gnatformat or gnatpp. VS Code allows you to choose, though the default is gnatformat; ada-ts-mode only allows gnatpp (pretty_printer).
At the moment, ada-ts-mode will (usually) adjust the case of an identifier to match the corresponding declaration, including declarations in the standard library, which is pretty cool.
