FreeTDS Development Group

[ZIGLIO Frediano <Frediano.Ziglio AT vodafoneomnitel.it>]

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

> > - rpm snapshot (built every day)
> 
> In principle, OK.  In practice, the nightly snapshot is built 
> on a NetBSD
> machine.  I don't know  if the tools for building a (source?) rpm are
> available on that platform.  
> 
> What we could perhaps do is let you build the nightly rpm, 
> and enable you to
> to scp the file to my build box, which would then upload it.  
> But I will
> look for rpm tools first.  
> 

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

> > 3) distribution
> > Why do not use a date instead of a version for releasing 
> > snapshot. So we can
> > release snapshot always with updated version
> 
> Interesting idea.  You mean, for the purposes of the nightly 
> build, change:
> 
>       AM_INIT_AUTOMAKE(freetds, 0.60)
> 
> to something like:
> 
>       AM_INIT_AUTOMAKE(freetds, 0.60-20021031)
> 
> Can do.  
> 

Ok, I prefer only the date but is the same...

> > 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.
> 
> I think this would be counterproductive.  Oftentimes we say to someone
> experiencing a problem, "get the nightly snapshot and show us 
> a backtrace".
> The more debugging information, the better.  What do you want 
> that strip(1)
> doesn't do for you?  
> 

strip remove debugging information, not debugging code. All assert or
logging are still there...
Also I think that user that require a snapshot version should not enable
these options and do not strip executable...
OT: I think I like in MS environment is the separate debug. Just add a
pointer in compiled code and put debug information in a separate file.

freddy77

=================================
"STRICTLY PERSONAL AND CONFIDENTIAL

This message may contain confidential and proprietary material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please contact
the sender and delete all copies.
The contents of this message that do not relate to the official business of
our company shall be understood as neither given nor endorsed by it."

=================================