Re: Error building APL

[Rowan Cannaday]

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 <address@hidden> 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' ||
>>     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
>>
>