What about excluding certain "error on warning" flags, except when compiling in developer mode?
For example, make `CXXFLAGS=-Werror=maybe-uninitialized ./configure` the default and force an error when configuring with `DEVELOP_WANTED=yes`. - Rowan On Fri, May 1, 2020 at 6:41 PM Dr. Jürgen Sauermann < mail@jürgen-sauermann.de> wrote: > Hi Peter, > > my experience with cmake is rather bad. I once wanted to install a rather > trivial source package whose build was based on cmake. It turned > out that installing cmake itself was rather awkward and took far longer > than the package that I originally aimed at. This was, of course, before > apt and friends so you had to manage cmake's dependencies manually > (and recursively). > > With GNU APL I wanted to save the user's that trouble. The beauty of > ./configure is that it works without installing the autotools. > > Best Regards, > Jürgen > > > On 5/1/20 8:28 PM, Peter Teeson wrote: > > Is there a place for using CMAKE? > Abstracting the global aspects? > Or alternatively just no longer supporting older releases of OS’ and > Compilers? > > Just musing. > > Peter > > > On May 1, 2020, at 1:48 PM, Blake McBride <[email protected]> wrote: > > 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 >> <http://bif_oper1_reduce.cc>' || >> >> echo './'`Bif_OPER1_REDUCE.cc <http://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 >> <http://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 >> >> >> > >> >> > >
