suggestion regarding the error message when using alr with: "underscores" are also allowed

[kwolcott]

suggestion regarding the error message when using alr with: "underscores" are also allowed

alr --no-color with gnatcoll-gmp
ERROR: Invalid name 'gnatcoll-gmp': Identifiers must be lowercase ASCII alphanumerical. You can see the complete identifier naming rules with 'alr help identifiers'
hamming: alr help

The following works:
hamming: alr --no-color with gnatcoll_gmp

[Fabien-Chouteau]

Indeed we can have a special handling for - because people are likely to use it.

[Joebeazelman]

I just discovered a bug with Alire. If you create child project that inherits from a parent project, such as first_parent.child, the compiler will complain that both the GPR file and its parent folder must be named using the following convetion, first_parent-child. In order for Alire to compile the project, the name attribute in alire.toml must be updated. Unfortunately, Alire reports the following error:

Invalid name 'first_parent-child': Identifiers must be lowercase ASCII alphanumerical. You can see the complete identifier naming rules with 'alr help identifiers'

How do you resolve this?

[mosteo]

There's no obligation that GPR files and the crate name match (although it's recommended to avoid surprises). In this case, I'd name the crate first_parent_child and use the project-files property in alire.toml to list the proper GPR file.

[Joebeazelman]

OK. So the name refers to the crate, whereas project-files refers to one or more associated project files. By default, when project files are unspecified, the crate and project names are the same even though their respective string requirements are incompatible? Even if I had considered this solution, I would have ruled it out by presuming they would be the same leading to the same error. Does project-files only refer to GPR files, or other project types, including make files, msbuild, etc.? For multiple projects, does the ordering of the projects in the list determine their build order? There's a lot of other nuances here that's not discussed, such as whether each GPR project has its own environment when executed by Alire, which I presume they do.

It might make sense to generate both project-files and name attributes in the alire.toml file to clue the user in on their differences when initializing a crate. It would also be very helpful if Alire suggests specifying or validating these attributes when reporting it can't find a project file.

I would be more than happy to submit documentation pull requests. I am, however, a strong believer in self-documentation. Error messages, help screens, and nomenclature should provide the majority of the documentation. For instance, if project-files ultimately refers only to GPR project types, it should be named `gpr-project-paths'. I use paths since files tend to refer file names and implies projects are in the same folder.

[mosteo]

Yes, but note that for a valid crate name, the default project file name will always be valid, and Alire won't initialize a crate with an invalid name.

As of today, project-files refers only to GPR files. These will be added to the autogenerated configuration files when doing an alr with. These are also the ones used to build the crate, in the order given. Each build invocation is separate, but the build environment will be the same, as it is set up before invoking gprbuild.

Although outside of Alire it may make sense to have several project files, within Alire (at least for now), there isn't much reason to have several project files, besides maybe organization, as they're all used in all-or-none fashion (you can't select a subset).

I see your point about documentation, and I mostly concur. Now that we have templates that allow easy maintenance of generated files, I'd like to have a switch in init that explicitly generates all fields in alire.toml with accompanying comments, as is typical in many unix config files.

And, of course, all contributions are gladly welcome.