[unixODBC-dev] Intended use of odbcinst wrt log/ini/lst?

Nick Gorham nick.gorham at easysoft.com
Wed Mar 30 17:44:14 BST 2005


Eric Sharkey wrote:

>>>There seem to be three sensible options:
>>>
>>> 1. odbcinst provides log/ini/lst (unixODBC 2.2.10 and eariler)
>>> 2. odbcinst does not provide log/ini/lst, but these are available
>>>      as separate installed libraries provided by unixODBC
>>>      (i.e., they get installed when you run "make install")
>>> 3. no part of unixODBC provides log/ini/lst, but these libraries
>>>      are available as a separate source package, independently
>>>      compilable/installable
>>>(4). log/ini/lst are internal to unixODBC and not available
>>>     as a standard package (this seems to be the current situation)
>>>
>>>Which of these are you intending, or if none, how is this supposed to
>>>work?
>>> 
>>>
>>>      
>>>
>>I guess 4. The idea was to provide all but no more than is provide under 
>>windows. I think adding 2 would work for me, but I would prefer that the 
>>driver manager and odbcinst use convienence libs so there are less deps 
>>fpr installers to worry about.
>>    
>>
>
>Hmm.
>
>I'm looking over the automake manual now.  Is there any reason why
>you can't LIBADD a library declared as lib_LTLIBRARIES the same way
>you can LIBADD noinst_LTLIBRARIES?  I don't see any reason why simply
>changing log/ini/lst into installable libraries would prohibit
>continuing to encapsulate them as private routines in
>libodbc/libodbcinst.
>
>  
>
>>The idea of unixODBC (at least the core components) providing more than 
>>the ODBC API worries me, as we then get problems when they are removed 
>>or changed.
>>    
>>
>
>I suppose you could make a case that unixODBC should be split into
>separate source packages precisely because of this.
>  
>
Yes, I think that would be a good goal. It would help a lot. I was 
intending to look into this when the testing work you wre doing had 
settled down.

>There's a lot of code in unixODBC now and it doesn't really all need
>to be built simultaneously.  Having the support libs, the core API,
>the drivers, and the GUI tools separated into four or more separate
>source packages would tend to simplify things, I think.
>  
>
Yes.

>  1. The support libs need to be available to drivers built using
>     the template.  This means they need to be compilable/installable
>     on all platforms, including Windows, where the unixODBC DM probably
>     isn't desired.
>
>  
>
Yes, again.

>  2. Having drivers, especially the template, build as separate
>     standalone packages simplifies driver development.  Having the
>     template so tightly integrated into the unixODBC build is
>     a little weird.
>
>  
>
And again, we agree.

>  3. It could eliminate the circular build dependency with qt, since
>     the DM could be built before qt, and then qt built on top of
>     unixODBC, and then the unixODBC GUI tools on top of qt.
>
>What do you think?
>
>  
>
See above :-)

>>FWIW, if I was starting again, I would argue strongly to provide the 
>>option of XML based config files.
>>    
>>
>
>I think that's an orthogonal issue.
>
>  
>
Yes, was but a passing comment.

-- 
Nick



More information about the unixODBC-dev mailing list