Don't treat warnings as errors

[krischik]

Make it possible to make development build when there are warnings. Treat errors as warnings is fine for release builds but it's huge hinderance for development. I don't need perfectly formatted code to run the debugger or the unit tests. For development I want quick turnarounds.

Please add an option to disable -gnatwe for faster development.

Note that switching off warnings entirely is not a good option either as I don't want to be surprised be warnings when doing the release compile.

[Fabien-Chouteau]

Hi @krischik ,

It should already be the case. The default profile mode is development in which warnings are not treated as errors. Can you show us the content of the files in the config/ directory?

The validation profile (alr build --validation) on the other hand, enables warnings are error.

[krischik]

My config directory changes as I use different profiles for different purposes. Which means that it could well be that --validation was active as I used validation to check contracts. Now that I know how it's supposed to work I will have a closer look at the active profile when compiling.

[krischik]

Just tried it again and:

>alr build --development
ⓘ Building adacl/adacl.gpr...
Compile
   [Ada]          adacl-strings.adb
/Users/Shared/Work/Projects/AdaCL/adacl/src/adacl-strings.adb:592:10: warning: "Start" is not modified, could be declared constant [-gnatwk]

   compilation of adacl-strings.adb failed

gprbuild: *** compilation phase failed
error: Command ["gprbuild", "-s", "-j0", "-p", "-P", "/Users/Shared/Work/Projects/AdaCL/adacl/adacl.gpr"] exited with code 4
error: Compilation failed.

This is so frustrating. I'm in the development phase and I don't care constants right now. This is just too strict for development.

[Fabien-Chouteau]

As I said this is not the expected behavior. Can please share with us some details on how to reproduce the case?
What is the content of config/config_adacl.gpr? What is the content of alire.toml?

[mgrojo]

I think I'm also reproducing this using these steps:

   alr init --bin issue_1386
   cd issue_1386
   alr with ashell
   alr build

There's a missing dependency and I don't know if it's relevant:

Changes to dependency solution:

   New solution is incomplete.
   +  ashell        1.3.0  (new)                 
   +  florist_blady 6.0.0  (new,indirect)        
   +⚠ gcc           11.2.4 (new,missing,indirect)

Do you want to proceed?
[Y] Yes  [N] No  (default is No) y

Compilation of Florist fails due to a warning:

posix-signals.ads:39:06: warning: unnecessary with of ancestor [-gnatwr]

   compilation of posix-signals.adb failed

gprbuild: *** compilation phase failed
error: Command ["gprbuild", "-s", "-j0", "-p", "-P", "/tmp/issue_1386/issue_1386.gpr"] exited with code 4
error: Compilation failed.

grep -r gnatwe inside this crate directory finds nothing.

Cannot be reproduced using withing directly florist_blady.

Investigating this I reached to Blady-Com/florist#6, so maybe @charlie5 reproduced it also, or even it is expected by him, although I cannot see nothing in either his crate or florist that includes the switch -gnatwe. Can it be activated in some other way?

#1209 might also be related.

[mgrojo]

I have to add something, the switch is in fact inside florist_blady, but I had to search for -gnatw.*e as those switches can be joined together.

alire/cache/dependencies/florist_blady_6.0.0_3bc476cc/florist.gpr:            for Default_Switches ("Ada") use ("-g", "-gnatw.eH.YD", "-gnatyg", "-Wall",
alire/cache/dependencies/florist_blady_6.0.0_3bc476cc/gnatsocks/gnatsocks.gpr:            for Default_Switches ("Ada") use ("-g", "-gnatwae", "-gnatyg");

So I guess the problem comes from that in my case. The only part that I don't understand is why these other steps (directly withing florist_blady) do not raise the same problem. I see warnings in the compilation also in this case, but the -gnatwe seems to not be applied.

   alr init --bin issue_1386_2
   cd issue_1386_2
   alr with florist_blady
   alr build

I suppose Alire is doing something different in this case, like building the florist_blady with the new crate GPR (issue_1386_2/issue_1386_2.gpr). But in principle, it doesn't seem its fault, since -gnatwe is actually requested by the dependency.

I've opened an issue in Blady-Com/florist#7

@krischik, I guess, also in your case, running grep -r -- '-gnatw.*e' will uncover the offender.

[mgrojo]

The only part that I don't understand is why these other steps (directly withing florist_blady) do not raise the same problem. I see warnings in the compilation also in this case, but the -gnatwe seems to not be applied.

I've seen something else that explains this, and it is not Alire's fault. It can only be said, that it could do something to warn about this kind of inconsistencies done by the user, if possible and convenient, which I don't know.

The question is that the crate ashell is withing florist.gpr in its crate project file, but this is not the project file given by florist_blady to alire (the Alire version is lib_florist.gpr, which doesn't have the -gnatwe as one expects for a library for distribution). This is why florist_blady is failing to compile only when built through ashell.

I suppose this wouldn't happen if the crate configuration model were used.

I opened charlie5/aShell#7 for this, so I won't spam this issue anymore.