[unixODBC-dev] unixODBC-GUI-Qt: Builds

Peter Harvey pharvey at peterharvey.org
Tue Dec 9 18:09:22 GMT 2008

> Well, its configured and seems to be building fine at this moment,
> good work. What do you want to do with odbctest? Its a bit of a half
> way house, can't help thinking it should go with the Gui parts as it
> is one, What do you think? If that (and the associated test lib and
> sample that goes with it) was removed, then all the GUI parts could be
> removed (I think).
> We also need to work on the web site, so there is a place for both
> projects, and people can find how to get the bits they need. Also the
> drivers need splitting out as well, so the folk who needs the txt
> driver can get their builds working again.
> BTW, if anyone else reading this has any views on this division, let
> me know, as I don't want to do stuff thats going to break others work.

re. odbctest

I think odbctest should be with unixODBC-GUI-Qt. I can get it in there
if you like?

re. gtk

The only other GUI bits would be gODBCConfig (I think). My thinking is
that a unixODBC-GUI-Gtk project would handle that. I have no plans to do
that work but I could, if need be, init the project so it can be removed
from the unixODBC-core.

re. web site

I was going to put some web material for unixODBC-GUI-Qt on the
sourceforge space but it probably makes more sense to just link people
over to a revised unixodbc.org. I think this is what you are suggesting
and if so - do you have a resource for this? I could do it in a pinch -
just not really my thing.

re. txt driver

I have plans to do *something* with the text file stuff - including the
txt driver. I need to see about getting it into a sourceforge project
itself and then see how much time I have for it. At a min I want to see
that stuff, in its current state, available and usable to people.

re. driver setups

My understanding is that you will remove all drivers from unixODBC-core?
What about the DRVConfig stuff? I do not see an obvious vehicle for
delivering DRVConfig to people - other than unixODBC-core. Perhaps
rethink how GUI abstracted (if any) driver setups should be done?

re. test framework & tests

Should these be their own project? Perhaps look at that at a later date?


More information about the unixODBC-dev mailing list