[unixODBC-dev] Files in CVS that should not be?

Nick Gorham nick.gorham at easysoft.com
Mon May 14 10:03:34 BST 2007


Kent Boortz wrote:

>Hi,
>
>I'm working on enabling "make dist" to work in the CVS version, and
>found some "Makefile.in" files to be checked into the CVS repository.
>I think they should not be under CVS control, or?
>
>  unixODBC/DataManagerII/Makefile.in
>  unixODBC/Drivers/MySQL/Makefile.in
>  unixODBC/Drivers/MySQL/samples/Makefile.in
>  unixODBC/gODBCConfig/Makefile.in
>  unixODBC/gODBCConfig/intl/Makefile.in
>  unixODBC/gODBCConfig/po/Makefile.in.in
>  unixODBC/libltdl/Makefile.in
>  unixODBC/DataManagerII/Makefile.am~    <<< emacs backup file checked in
>  odbctest/C:\IB6TRACE.LOG               <<< garbage checked in?
>
>Not near finished, but as there are things that you might prefer to
>remove from the CVS source repository instead of adding to the source
>distribution, I include my first version of the patch.
>  
>
Ok, I will look at removing them. The log file ins't in the source 
distribution BTW.

The Makefile.in's are in the distrib for platforms that don't have their 
own automake installed, I don't see the real problem.

>As you don't seem to have some daily build to check that "make dist"
>works, I have used the feature of automake that you can give a
>directory name to EXTRA_DIST, and a top level "dist-hook" target to
>remove the "CVS", ".libs" and ."deps" directories before packaging.
>  
>
Well, we don't have a daily make dist, as it tends to be me that does 
the builds, and me that people send patches to.

>The advantage with giving a directory to EXTRA_DIST is that you don't
>have to list all files, the drawback is that if you do "make dist" in
>a source tree you have built in, you might get garbage into the
>created source TAR.
>  
>
Err, so where is the advantage over what we have now? All I can see is 
it means the extra files which I don't think of as a problem becomes a 
problem.

>Maybe the bundled old obsolete MySQL driver should be removed from the
>unixODBC sources? :-) Or create a directory "historical" and move all
>stuff there that is not really for distribution, and maybe one
>"experimental" for things not really completed, and move some stuff
>there? Or just add to the top README.cvs what is obsolete or not?
>
>  
>
Well, I added it on MySQL request, happy to remove it as well. However 
your patch makes it build as part of the main tree. Thats not what I 
want to happen at all,  it means the buld will break if you don't have 
the required libs, thats why its optional.

Also your patches adds various makefiles and projects, at the moment the 
code builds using the standard unix tools, I have enough trouble as it 
is keeping the QT code building as TT change stuff. Not sure where 
DriverManager.vpj came from in CVS for example (ok I know I can check), 
but I don't think it needs to be in the distribution IHMO.

-- 
Nick Gorham
Easysoft Limited
http://www.easysoft.com, http://www.unixODBC.org




More information about the unixODBC-dev mailing list