[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] -Wall checked in
From: |
Gregory Wright |
Subject: |
Re: [Gcl-devel] -Wall checked in |
Date: |
20 Jul 2002 12:58:08 -0400 |
Hi Camm,
On Sat, 2002-07-20 at 03:25, Camm Maguire wrote:
> Greetings! Am pleased to announce that I just checked in a rather
> large mod to get a clean build under -Wall. Several issues uncovered
> and addressed at least preliminarily. maxima 5.6 and cvs build and
> run fine, and gcl compiles itself as well as ever. Seems slightly
> faster too, though this is not a scientific observation. we'll see
> shortly how the Debian autobuilders like this one.
>
> Please test thoroughly.
>
> Just a few notes for the future:
> 1) It would be nice to find a way to go completely with ANSI C
> varargs, in place of the traditional method. The problem here is that
> one cannot represent *all* args as variable in this way, and such a
> possibility is built in to the code in funlink.c (c_apply_n).
ANSI C would be good. It does bring up the interesting policy question:
should gcl work with any compiler other than gcc? Does anyone use it
with something else? I ask because it affects how much cruft can be
removed from the configure.{in,ac} (see below).
>
> 2) Need to minimalize the new header h/protoize.h
>
> 3) Need to declare all functions with proper arguments -- right now
> gcl requires certain functions to be declared with an empty
> argument list to pass the function pointers around correctly.
>
> 4) Need to revisit the 'lintian' changes I've made to the list
> compiler. Several unused variables should not be declared, rather
> than the empty use of said variables I've inserted into the C
> output. Likewise with unused labels.
>
> 5) Need to beautify and clean the code at some point. Changes made
> thus far were minimal for -Wall, and not intended to change
> functionality (significantly).
Yes, there are some stretches of code that are hard to read. Should a
standard 'indent' command be used on the C and the lisp run through an
agreed upon pretty printer?
>
> 6) Need to finalize the build method, modern makefiles, have configure
> spit out most if not all what we put in by hand not in *.h
>
I'll suggest automake + autoconf for developer builds; this won't affect
users who will still be able to build with ./configure && make && make
install.
The possibly disruptive change is cleaning up the directory structure.
We should probably move the build support (e.g., add-defs) into a
scripts directory. This aligns us with the standard gnu-ish tree: top
level is essential documentation (README, INSTALL), build scripts
(configure, Makefile.*) and subdirectories for all of the code. This
structure helps keep automake's makefiles clean and easy to manage.
I'd be happy to work on this since I've already started.
> 7) Need to turn to ansi compliance, import clocc test tree.
>
> 8) Need to have a sfasldlsym.c option where bfd doesn't work, or get
> bfd to work everywhere :-).
>
> 9) release 2.5.0, not necessarily in this order :-)
>
> Take care,
> --
> Camm Maguire address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
--
Gregory Wright
Chief Technical Officer
PacketStorm Communications, Inc.
20 Meridian Road
Eatontown, New Jersey 07724
1 732 544-2434 ext. 206
1 732 544-2437 [fax]
address@hidden