gcl-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]