> -----Original Message-----
> From: Stephen torri [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 05, 2003 10:44 PM
> To: cryptopp
> Subject: RE: Regarding warnings
> 
> On Wed, 2003-11-05 at 21:27, Shawn Masters wrote:
> >     It has always been accessible to unix users.  Unpack and build.  I
> > think what you are talking about is packaging.  Considering this is
> aimed at
> > developers I think time would be better spent on code then packaging,
> but if
> > you feel inclined...
> >
> >     73,
> >             Shawn
> 
> I would submit it if Wei thought it to be useful for Unix/Linux users.
> You are right in saying that it has been accessible to unix users
> already.
> 
> I cannot say I agree completely with only getting it warning free on
> Windows only. If we do release on non-Windows platforms then we must at
> least select a set of compilers which we will support. In practice I
> feel , (my opinion ofcourse), that all the compilers supported should be
> warning free.

        The quest for being warning free may be too much of a blind
ambition.  I do agree that all warnings need to be addressed, but fixing
code to eliminate every single one of them can cause code that is harder to
read and maintain.  Lets face it, some warnings are just compiler developers
opinions which may or may not be valid in context.  They should not be
ignored, but that doesn't mean the greater good is in removal in all cases.


        If you want to really get nuts though, feel free to fix all of the
lint statements :-).  
 
> Ofcourse changes for one compiler may not work for others. This is the
> reasoning behind my suggest for autoconf. With autoconf we can detect
> the system can the compiler in use. Armed with that fact we can be sure
> that any gcc specific code would not interfere with any MS code through
> the use of #ifdef statements.

        There is no need for autoconf to do this.  Look at Crypto++ now and
you will see #ifdef structures that change code for GCC versus BCC, etc.
Autoconf will get you the ability to change based on available subsystems
and specific implementations.  I don't think that is an issue currently.

        Of course it would be nice to go forward with an autoconf style
system in future development.
        
        73,
                Shawn
 
> Stephen
> --
> Stephen Torri
> GPG Key: http://www.cs.wustl.edu/~storri/storri.asc

Reply via email to