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

Eric Sharkey sharkey at netrics.com
Wed Mar 30 16:26:30 BST 2005

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


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

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

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.

  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.

  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.

  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?

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


More information about the unixODBC-dev mailing list