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
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
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
>>
>
|