Jim Bosch – Perry and Lauren raised this issue. My (simple, ugly) workaround was simply to add pragmas like this everywhere the warnings are occurring:

+    #pragma clang diagnostic push

+    #pragma clang diagnostic ignored "-Woverloaded-virtual"

    virtual void measure(

        afw::table::SourceRecord & record,

        afw::image::Exposure<float> const & exposure

    ) const = 0;

+    #pragma clang diagnostic pop

Before just ploughing ahead with that, I wanted to check that you don't have a more elegant suggestion.

A better fix would be to add using SimpleAlgorithm::measure; to the declaration for ApertureFluxAlgorithm, and any other class that exhibits these warnings.

And I of course agree we should make the struct/class usage consistent; that's always something I fail to notice, since I'm essentially always compiling with gcc and it never complains about it.

A better fix would be to add using SimpleAlgorithm::measure; to the declaration for ApertureFluxAlgorithm, and any other class that exhibits these warnings.

That's clearly the right thing to do, but won't it confuse SWIG? I've not tried it, but I thought that was the point being made by the design notes.

Having actually looked at the code, I think adding a using declaration is fine so long as it's also private. Given that, it's clearly better than faffing with the compiler warnings.

I think it'd be fine public as well. I think Swig was only confused to the extent that it simply ignored the using declaration, not that it caused problems. Of course, if you've found a case where it does cause problems, just ignore me.

I've not looked hard, but just whacking in a public using breaks:

python/lsst/meas/base/baseLib_wrap.cc:21816:59: error: 'measure' is a private member of

      'lsst::meas::base::PsfFluxAlgorithm'

      ((lsst::meas::base::PsfFluxAlgorithm const *)arg1)->measure(*arg2,(lsst::afw::image::...

      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~

include/lsst/meas/base/PsfFlux.h:91:18: note: declared private here

    virtual void measure(

But a private version quiets the errors and doesn't seem to cause any problems, so that's an easy solution.

Hmm. I'm starting to think we'd be better off with an entirely different solution: making all of the measure methods and using declarations public, but putting them inside #ifndef SWIG blocks.

I'd like to give that a try, but feel free to just reassign to me if you need to be working on other things this weekend.

Yes, I like that solution better. I tested it on meas_base and it seems to work fine. Since there's no real urgency here, I'll hold off on finishing up this ticket until DM-982 (update photometryKron to new framework) & maybe DM-981 (ditto for shapeHSM, although that looks less imminent) have landed so I can make the same changes there on the same ticket.

...also DM-980.

It'd be nice to get this landed in W15, but it's in the queue behind DM-980/1/2 before it can be merged.

However... the changes associated with those should basically be carbon copies of the changes I've already made in tickets/DM-2131 on meas_base; my suggestion is that if you're happy with the changes here, I can do the same thing on the other repositories without further review (assuming that all the tests pass, etc). Is that fair?

I am indeed happy with all of the above. Those particular warnings are now gone and all tests passed, so feel free to make and merge the other related changes when you can without further review.

Jim – following our discussion, I tweaked meas_base to disambiguate measure and measureForced. Changes on tickets/DM-2131 in meas_base. Passes the tests there, and also resolves my issues in ip_diffim.

I realise you are snowed under with end-of-cycle reviews, but could you give it a quick check to make sure it's what you had in mind?

Also, since this is a change to the previously-agreed interface, any thoughts on whether it needs RFC-ing? My feeling is no.

Looks good; sorry it took me so long to take a look at this. I agree that this shouldn't require an RFC.

Thanks! ("So long" being two weekend days? Hmm...!)

I'd like to land this now, but it turns out I need to install GalSim before I can test on shapeHSM, and I doubt that's going to happen before I have to bump this to S15.