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

Nick Gorham nick at lurcher.org
Mon May 14 11:42:08 BST 2007


Kent Boortz wrote:

>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//
>  
>
No you are right it shouldn't be in the CVS, I will remove that.

What I meant, is when I do a make dist, it doesn't get in the tarball.

>  
>
>>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 :-)
>
>  
>
That I guess is a fault with whats in CVS, I have a directory here that 
I build the releases from, I will check.

>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.
>
>  
>
I expect it is.

>>>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.
>
>  
>
Yes, I use make dist, maybe I should check what stops a make dist from a 
clean tree.

>>>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.
>  
>
No its entirly different, thats the way I was asked to do it.

>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.
>
>  
>
Oh, I agree, as I say, I was asked to put it there, so I did, happy to 
remove again, as you say its way out of date.

>>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,
>
>  
>
I will try and see why your make dist fails (maybe at the weekend).

-- 
Nick



More information about the unixODBC-dev mailing list