jan damborsky wrote: > Alok Aggarwal wrote: >> Hi Dave, >> >> On Mon, 1 Dec 2008, Dave Miner wrote: >> >> >>> Please review the fix for >>> >>> 5468 gui-install should be delivered in a separate package to tighten >>> dependency graph >>> http://defect.opensolaris.org/bz/show_bug.cgi?id=5468 >>> >>> Webrev is available at: >>> >>> http://cr.opensolaris.org/~dminer/slim_5468/ >>> >> >> SUNWinstall/prototype_com: Is the removal of transfermod.h >> (and maybe ti_api.h as well) intentional? I ask because >> in the past when this file has been missing on the target >> system, the transfer module fails to run. I'm not sure if >> that still is the case or it has been restructred to not >> require the header file. >> > > It seems they are still needed - probably used for dynamically > generating Python definitions: > > $ ggrep -Rl transfermod ./ > ... > ./lib/libtransfer/transfer_defs.py > ... > > $ ggrep -Rl ti_api ./ > ... > ./lib/libti_pymod/ti_defs.py > ... >
Thanks for pointing that out, guys. I hadn't had a chance to test an image with this yet, so hadn't found it. Obviously, I'm surprised, and I can only say that I'm horrified by both of those modules, because while they provide common values, they don't provide common definitions, so you still have multiple places to update for each new define that's shared, which is the primary thing you're trying to avoid! The suggestion I had made to someone (don't recall who it was now) when this first came up was to do what I had done for a similar problem in sharing definitions between Java and C back in dhcpmgr: use m4 to to generate both a C header file and a class or module. That solves the whole problem. I will grant that m4 isn't something that's perhaps familiar, but it isn't hard to figure out. See http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdhcpsvc/head/dhcp_svc_confkey.m4 for the example of what I did all those years ago. I'll file a bug and revert that part of the change. Dave
