track_oracle fails to build unless KWIVER_ENABLE_VXL is ON

[mwoehlke-kitware]

Naïvely turning on KWIVER_ENABLE_TRACK_ORACLE results in a slew of build errors (missing includes), due to hard dependencies on VXL.

I'm not sure what's the best solution; is it too heavy-handed to simply require VXL? Should we try to make it a soft dependency? (I suspect this would be hard, although I do wonder if we should be using KWIVER types instead of VXL types. This would probably be a major porting headache for users, especially as it would seriously wreck any chance of VidTK compatibility, but it might be TRTTD in the long run.)

[collinsr]

Most of the vxl dependencies are vgl-- lots of use of vgl_box_2d etc. I think it's mostly simple data structures on the track_oracle side, although the scoring code uses some algorithms (intersections, etc.) If vxl is not reliably available then switching over to vital is probably the right move.

On Tue, Nov 5, 2019 at 1:49 PM Matthew Woehlke notifications@github.com wrote:

Naïvely turning on KWIVER_ENABLE_TRACK_ORACLE results in a slew of build errors (missing includes), due to hard dependencies on VXL.

I'm not sure what's the best solution; is it too heavy-handed to simply require VXL? Should we try to make it a soft dependency? (I suspect this would be hard, although I do wonder if we should be using KWIVER types instead of VXL types. This would probably be a major porting headache for users, especially as it would seriously wreck any chance of VidTK compatibility, but it might be TRTTD in the long run.)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Kitware/kwiver/issues/898?email_source=notifications&email_token=ABYLWJGDCYO4BRFAS5LSPS3QSG53FA5CNFSM4JJGTLB2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HW7ONLQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYLWJBSK5PKJEV4SSM2SYDQSG53FANCNFSM4JJGTLBQ .

[dstoup]

Is there a good reason not to require VXL for track_oracle, at least in the short term? I mean, it's nice to minimize deps but using vital types is a big change for users, especially vidtk where I'm still hoping to eliminate the duplicated track oracle code base.

I wouldn't mind changing other packages to use vital types with track_oracle but that does seem like a major undertaking.

On Tue, Nov 5, 2019 at 2:04 PM Roddy Collins notifications@github.com wrote:

Most of the vxl dependencies are vgl-- lots of use of vgl_box_2d etc. I think it's mostly simple data structures on the track_oracle side, although the scoring code uses some algorithms (intersections, etc.) If vxl is not reliably available then switching over to vital is probably the right move.

On Tue, Nov 5, 2019 at 1:49 PM Matthew Woehlke notifications@github.com wrote:

Naïvely turning on KWIVER_ENABLE_TRACK_ORACLE results in a slew of build errors (missing includes), due to hard dependencies on VXL.

I'm not sure what's the best solution; is it too heavy-handed to simply require VXL? Should we try to make it a soft dependency? (I suspect this would be hard, although I do wonder if we should be using KWIVER types instead of VXL types. This would probably be a major porting headache for users, especially as it would seriously wreck any chance of VidTK compatibility, but it might be TRTTD in the long run.)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < https://github.com/Kitware/kwiver/issues/898?email_source=notifications&email_token=ABYLWJGDCYO4BRFAS5LSPS3QSG53FA5CNFSM4JJGTLB2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HW7ONLQ , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABYLWJBSK5PKJEV4SSM2SYDQSG53FANCNFSM4JJGTLBQ

.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Kitware/kwiver/issues/898?email_source=notifications&email_token=ABKEAWUUPOMARDI233K3JNDQSG7TTA5CNFSM4JJGTLB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDD6J6I#issuecomment-549971193, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKEAWXSPEN4OUOCLFXE3ADQSG7TTANCNFSM4JJGTLBQ .

-- David Stoup Principal Engineer

Kitware, Inc.

1712 Route 9, Suite 300 Clifton Park, NY 12065-3104 518-881-4949 (W) 518-312-3946 (M) 518-371-4573 (F)

[mwoehlke-kitware]

Is there a good reason not to require VXL for track_oracle, at least in the short term?

In the short term, probably not. Mostly I wonder if we are okay with just find_package(VXL REQUIRED) or if we want to make it more obvious somehow that we need VXL because the user asked to turn set KWIVER_ENABLE_TRACK_ORACLE=ON.

In the longer term...

I think it's mostly simple data structures on the track_oracle side

...this is why I wonder if we shouldn't try to port off of VXL and use KWIVER (i.e. Eigen) data structures instead. First, because it would improve track_oracle's integration into KWIVER, and second because I wonder if we even need VXL.