Dave Miner wrote: > 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 > >
I am no familiar with m4, but looking at this file for a while, the idea is understood :-) I agree using such approach would solve that problem in clean way. Jan
