I'm not too worried yet - the inciting incident was a breakage using the Ninja Multi-Config generator that traced back to configure_file function wrapping, and Ninja Multi-Config is only being used right now for BRL-CAD as a convenient way to test multiconfig build logic on Linux. The response to the issue I filed indicated that we can't consider function wrapping a "technically supported use case" - i.e. if it breaks in more subtle ways than the infinite looping (which it did, at least in this case) we *may* be out of luck. Given that, it seemed like now (*before* we have any significant issues) was a good time to revisit the wrappers and see what we still actually need.
Fortunately, it looks like CMake 3.7 introduced the key missing pieces to allow the removal of most of our wrappers. That's worthwhile just for the simplification of our own logic, irrespective of the question of unsupported behavior... The message() use case is the only remaining wrapper from the original 2015 use case list ( https://cmake.org/pipermail/cmake-developers/2015-July/025640.html) that I've not identified a replacement feature for (as yet). Agreed - shouldn't remove it until I can either replace the functionality or the wrapper does actually break something. In some ways message() is a lot simpler since it's not directly tied up with the build system generators, so hopefully simpler translates as "less likely to break"... Using ExternalProject_Add offers some new options for 3rd party build logging and as separate builds message calls won't tie into our system anyway, so it may actually be more practical post-switch to define a BRL_MSG function in the vein of BRLCAD_ADDLIB et. al. to do the wrapping in a "standard" way. First though I've got to actually get the ExternalProject setup to build something on Windows... grr... Cheers, CY On Sat, Oct 17, 2020 at 2:26 PM Christopher Sean Morrison via brlcad-devel < brlcad-devel@lists.sourceforge.net> wrote: > I would note that while it’s discouraged, it’s just this guys opinion > subject to disagreement. It’s like saying operator overloading in c++ is > discouraged. > > There are perfectly sound cases where wrapping may still make the most > sense. *shrug*. The problem he identifies in that article with it is the > potential for an infinite loop. That’s not exactly a subtle problem and > one we’ve never encountered. The only way it would affect BRL-CAD would be > if another project linking BRL-CAD wrapped the same functions as us and > those wrappers were actually set up to call each other... > > That said, I’d agree that we should try to keep it to a minimum. I just > wouldn’t sacrifice anything for it until it’s a problem. Like our > message() wrapper.. > > That’s of course just my opinion too and subject to disagreement. :) > > Cheers! > Sean > >
_______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
