FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: ZIGLIO Frediano [mailto:Frediano.Ziglio AT vodafoneomnitel.it]
> Sent: October 28, 2002 10:58 AM
> > > 
> > > 2) snapshot build
> > > I think we should update our snapshot build process. Now the 
> > > only build is CVS snapshot. I'd like to add
> > > - documentation snapshot (so test users can try using update 
> > > documentation removing the need of docbook)
> > 
> > I don't understand.  The documentation is provided as sgml 
> > and html in the
> > nightly snapshot.  You can't "remove the need for docbook" if 
> > the UG is
> > maintained in docbook.  
> > 
> 
> I don't use very much snapshot (CVS is better), so perhaps things are
> changed from the last time I downloaded it...

Perhaps. :)  

Since I started taking care of the nightly build, we rely on "make dist".
The snapshot includes a .tgz of the UG html output in the the doc directory.
"make install" ignores it.  

> Another type of documentation if doxygen docs. Do you think that all
> developer should have doxygen installed (or do not use it) ? 
> Perhaps we
> should compile in our next release so user can use it too ?

That would be the Next Big Thing, documentation-wise.  As Brian pointed out,
we distinguish between maintainers and developers.  Maintainers have to have
documentation tools installed.  Developers may, but the Makefiles must not
require them; documentation will be built only if the tools are already
installed.  

Thus, if you want doxygen docs, you'll want doxygen first.  

I will install doxygen on the build box and include its output in the
snapshot in the same way as OpenJade's output.  

> > > - rpm snapshot (built every day)
> > 
> > I don't know  if the tools for building a 
> > (source?) rpm are available on that platform.  
> 
> Ok, to build rpm you need just rpm. Current version (4.x) use 
> a specific
> command (rpmbuild) for building. Just do a "rpmbuild -ta
> freetds-0.60.tar.gz" to build rpms for your platform... you 
> can build even
> for other platform if you have a cross platform compiler and tools...

I'll try to install rpm 4.x on the build box.  I'm intending a source rpm,
not an i386 binary.  OK?  

> > > 3) distribution
> >
> >     AM_INIT_AUTOMAKE(freetds, 0.60-20021031)
> > 
> > Can do.  
> > 
> 
> Ok, I prefer only the date but is the same...

My form makes it easier to know the base version.  If we make more frequent
(than once a year) releases, that would matter.  

> > > 4) new compile options
> > > Personally I hate debug code in release so I'd add a 
> > > --minimun-debug-level
> > > for disabling some debug/log code generation.
> 
> strip remove debugging information, not debugging code. All assert or
> logging are still there...

I see.  

I think assert() on most platforms is a no-op when compiled without -g (or
whatever "release mode" flags the compiler uses.  

We have two mechanisms available to quiet the debugging and logging output:


1.  #ifdef NDEBUG.  Is this standard?  Is any such thing?  
2.  g_debug_lvl.  I would prefer an enumerated type: 
    enum tds_debug_level {release, testing, debugging, insecure, maximum};
Functions to set/get g_debug_lvl (in src/tds/util.c), and the log writer
tdsdump_log() would respect the setting.  

Is that enough?  We could set the default to "debugging".  

On that topic, it seems we have eliminated login packets from the log.
That's more secure, but makes debugging login problems more difficult.  I
haven't looked into this, though, so I might be a little behind the state of
logging art.  

> Also I think that user that require a snapshot version should 
> not enable these options and do not strip executable...

Agreed.  Of course, you don't get a log file at all unless you define
TDSDUMP.  

Regards, 

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.