Hi Jürgen, Being the author of a portable, C-based Object-Oriented Extension to the C language (https://github.com/blakemcbride/Dynace) and the Kiss Web Development Framework (https://kissweb.org/), I sympathize with you. In fact, I would guess that I've spent nearly as much time with build systems and portability issues as I have on the systems themselves. With respect to Dynace, I had the same goals - build with no warnings. In the end, however, I found it impossible. I gave up, did what I could but ignored the ones that were BS.
I think it is very important that GNU APL build without investigation (looking at README-11-bogus-compiler-warnings). If GNU APL doesn't build out-of-the-box, most first-time users will give up and remove it. For this reason, I think allowing the build to proceed is very important. README-11-bogus-compiler-warnings can be used to explain the warnings and ways of eliminating them by lowering the warning level of the compiler. Meanwhile, when *you* build, you can pay close attention to the warnings to be sure you're not doing anything wrong. Having the build fail and forcing a new user to investigate the issue is a sure way to lose new users. Just some opinions. Thanks! Blake On Fri, May 1, 2020 at 10:52 AM Dr. Jürgen Sauermann < mail@jürgen-sauermann.de> wrote: > Hi Blake, > > this is kind of a dilemma. On the one hand I have the ambition that the > build should be as clean as > possible. In the majority of cases the warnings point at something that > needs to be improved. Many > reports come from platforms that I do not posses, or from a compiler > version that I do not use (like in > the example below). On the other hand the number of bogus compiler > warnings has increased > significantly in the last few years and the warnings get increasingly > stupid (e.g. -Wmisleading-indentation) > > The idea of *README-11-bogus-compiler-warnings* was to give the user an > idea of how to fix > a build that is broken by a new bogus compiler warning so that I can > prioritize the fix of the warning > a little down without loosing the reports about the warnings. > > Best Regards, > Jürgen > > > On 5/1/20 4:59 PM, Blake McBride wrote: > > Or, as a solution I've used in the past, don't kill the build on a > > warning. Just issue the warning and keep going. This is the default > > behavior of make. Errors are errors that should be fixed. Warnings > > are things the compiler points out that you may want to look into. It > > isn't saying they're wrong. > > > > I think it is often the case that making a few tweaks to minimize > > warnings is good. However, as you've noted, trying to eliminate every > > warning is more than a fulltime job. > > > > Thanks! > > > > Blake > > > > > > On Fri, May 1, 2020 at 9:43 AM Dr. Jürgen Sauermann > > <mail@jürgen-sauermann.de <mailto:mail@j%C3%BCrgen-sauermann.de>> wrote: > > > > Hi everybody, > > > > it seems like gcc/g++ continues to generate bogus warnings at a > > rate that makes it difficult to > > keep up with. For that reason I have written a > > *README-11-bogus-compiler-warnings* which > > explains how to deal with this. *SVN 1276*. > > > > Maybe somebody would like to report this as a compiler error. > > Strictly speaking it is not > > because the warning itself says "maybe", but IMHO it should not > > occur under *-Wall* > > but only under *-Wextra*. > > > > Best Regards, > > Jürgen > > > > > > On 5/1/20 4:06 PM, Blake McBride wrote: > >> Greetings, > >> > >> Trying to build GNU APL rev 1275 on my 64-bit Linux box I get: > >> > >> [...] > >> mv -f .deps/apl-Bif_OPER2_RANK.Tpo .deps/apl-Bif_OPER2_RANK.Po > >> g++ -DHAVE_CONFIG_H -I. -I.. -Wall -I sql -Werror > >> -I/usr/include -I/usr/include/postgresql -rdynamic -g -O2 -MT > >> apl-Bif_OPER1_REDUCE.o -MD -MP -MF .deps/apl-Bif_OPER1_REDUCE.Tpo > >> -c -o apl-Bif_OPER1_REDUCE.o `test -f 'Bif_OPER1_REDUCE.cc' || > >> echo './'`Bif_OPER1_REDUCE.cc > >> In file included from PrintBuffer.hh:30:0, > >> from Cell.hh:30, > >> from CharCell.hh:24, > >> from Value.hh:24, > >> from NamedObject.hh:25, > >> from Function.hh:27, > >> from PrimitiveFunction.hh:27, > >> from PrimitiveOperator.hh:24, > >> from Bif_OPER1_REDUCE.hh:24, > >> from Bif_OPER1_REDUCE.cc:23: > >> Shape.hh: In member function ‘Token > >> Bif_REDUCE::reduce_n_wise(Value_P, Token&, Value_P, uAxis)’: > >> Shape.hh:133:18: error: ‘shape_Z.Shape::rho[axis]’ may be used > >> uninitialized in this function [-Werror=maybe-uninitialized] > >> if (rho[r]) { volume /= rho[r]; rho[r] = sh; volume > >> *= rho[r]; } > >> ~~~~~^ > >> Shape.hh:109:41: error: ‘shape_Z.Shape::rho[axis]’ may be used > >> uninitialized in this function [-Werror=maybe-uninitialized] > >> { Assert(r < rho_rho); return rho[r]; } > >> ^ > >> Shape.hh: In member function ‘Token > >> Bif_REDUCE::replicate(Value_P, Value_P, uAxis)’: > >> Shape.hh:133:18: error: ‘shape_Z.Shape::rho[axis]’ may be used > >> uninitialized in this function [-Werror=maybe-uninitialized] > >> if (rho[r]) { volume /= rho[r]; rho[r] = sh; volume > >> *= rho[r]; } > >> ~~~~~^ > >> cc1plus: all warnings being treated as errors > >> Makefile:3234: recipe for target 'apl-Bif_OPER1_REDUCE.o' failed > >> make[3]: *** [apl-Bif_OPER1_REDUCE.o] Error 1 > >> make[3]: Leaving directory '/home/blake/Backup/apl/src' > >> Makefile:4584: recipe for target 'all-recursive' failed > >> make[2]: *** [all-recursive] Error 1 > >> make[2]: Leaving directory '/home/blake/Backup/apl/src' > >> Makefile:522: recipe for target 'all-recursive' failed > >> make[1]: *** [all-recursive] Error 1 > >> make[1]: Leaving directory '/home/blake/Backup/apl' > >> Makefile:409: recipe for target 'all' failed > >> make: *** [all] Error 2 > >> > > > >
