BUG: qt3 unixODBC recursive depends in variants

[yves@…]

in unixODBC :

variant gui {

depends_lib-append lib:libqt-mt.3:qt3

in qt3 :

variant odbc {

depends_lib-append lib:libodbc.1:unixODBC

Maybe this is not really a problem, but Should one variant supercede the other ? Or should it be made a recursive build ? Maybe just a little documentation embeded for each variant would help make things clearer.

[yves@…]

the unixODBC variant has a quirk

--with-qt-bin=${prefix}/bin

misses a "\" at the end

[simon@…]

(In reply to comment #1)

the unixODBC variant has a quirk --with-qt-bin=${prefix}/bin misses a "\" at the end

Submitted a fix for this. See bug 2864

[simon@…]

(In reply to comment #0)

in unixODBC : variant gui {

depends_lib-append lib:libqt-mt.3:qt3

in qt3 : variant odbc {

depends_lib-append lib:libodbc.1:unixODBC

Maybe this is not really a problem, but Should one variant supercede the other ? Or

should it be made a

recursive build ? Maybe just a little documentation embeded for each variant would

help make things

clearer.

I don't think that this is actually a problem. If I can explain,

qt3 (as far as I can tell) is an environment/program that lets you create graphical interfaces for other apps.

unixODBC has the ability to utilise qt3 to create a graphical interface for itself. I don't believe that qt3 requires unixODBC for unixODBC to do this.

qt3 has the ability to link against MySQL/Postgresql/unixODBC, giving qt3 the ability to create connections to the aforementioned db's/dsn in the final app. I don't believe that unixODBC requires qt3 for qt3 to do this.

[mww@…]

hmm... shouldnt then qt3 depend on unixODBC and a new port unixODBC-gui depend on qt3...?

[yves@…]

I think it is better as a variant, since the -gui port would have to delete every duplicate files in post- destroot and the port image mechanism makes it easy to switch to +gui

[rshaw@…]

No longer maintaining these ports.