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

Kent Boortz kent at mysql.com
Mon May 14 10:34:52 BST 2007


Nick Gorham <nick.gorham at easysoft.com> writes:
>>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.

I talk about the CVS tree, I don't know how you produce the source TAR
from that. I just assumed you don't use "make dist", as I found it to
be broken. I could be wrong of course, that something in my setup made
it break. I do think the LOG file is in CVS, but I could read it wrong
as well

  % grep LOG odbctest/CVS/Entries
  /C:\IB6TRACE.LOG/1.1.1.1/Wed Oct 17 16:40:31 2001//

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

Not all Makefile.am have a Makefile.in, I'm a build guy I have
problems with inconsistencies :-)

After a build a

  % cvs diff -uR

will show diffs on files that are generated. But if that is how you
want it, no problem. I just thought it was a mistake.

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

If you use "make dist" to create the source TAR you distribute, then
I guess a much smaller patch should be enough.

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

I assumed you did not use and test "make dist", and that with long
file listings you would never catch up. If you do use "make dist" and
update the listings, having file listings like now is better.

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

Ah, so it is totally separate, not to even be configured from top
configure? I guess I saw the other drivers were not handled the same
way and assumed it was a mistake.

So the MySQL driver put in there is the same as the one MySQL AB is
developing? MySQL AB is now active with providing driver releases
regularly, so I just fear the driver bundled with unixODBC will get
behind and cause confusion. But that is not my call.

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

Thanks for the clarification, I sure don't want to add more trouble. I
think I give up making "make dist" work and now switch to just package
all files in CVS and see if I can build on all hosts from that,

kent

-- 
Kent Boortz, Senior Software Developer
MySQL AB, www.mysql.com
Office: +46 18 174400 ext. 4450 (VoIP)
Office: +46 19 182931
Mobile: +46 70 2791171



More information about the unixODBC-dev mailing list