I think we've pursued this "shared source" issue enough in the context of this thread/case. I'd hoped to get some type of assurance that the getconf duplication was a short tem problem, but it seems not to be. That said, I'm not going to object to this proposal on the basis that it replicates a bit of source. Besides, if I understand the issues here, the cure of extensive Makefile munging may be worse than the disease.
thread closed. - jek3 Roland Mainz wrote: > Joseph Kowalski wrote: > >> Roland Mainz wrote: >> > [snip] > >> Maybe I'm just confused, but this seems to be a good explanation why >> /usr/bin/getconf >> can't be a tiny wrapper linking with the library which implements the >> builtins for ksh93 >> (I forgot name of said library - probably blocking it in the Freudian >> sense.) >> >> Why couldn't the same *source* be compiled not in xpg mode to produce >> /usr/bin/getconf. >> I believe the concern was about sharing source, not about sharing the >> binary implementation. >> > > Ouch... the getconf builtin needs libast (see Glenn's earlier email > about |astconf()|&co.) which means we would need two versions of libast > (compiled for both 32bit and 64bit (= four binaries)). Quick look at the > codebase: > $ du -ks src/lib/libast/common > 9505 src/lib/libast/common > ...which means it's not really "small". > Another problem is that we would have to generate the libast headers > four times: One time 32bit XPG6/C99, one time 64bit XPG6/C99, one time > 32bit "normal" and one time 64bit "normal". And we would have to test > the resulting ... uhm... "thing". > Once this is done we still hit the problem that the current process > defines the |_xpg4| and |_xpg6| variables and not the current library > we're currently executing. This means we need to |fork()|+|exec()| a new > process which uses these "special" XPG6-less libraries. At this point I > try t stop to imagine the horror of such a design... we would need to > ARC the new extra versions of the various AST libraries, need extra > testing etc. etc. And this doesn't even handle the siblings of > /usr/bin/getconf, e.g. /usr/xpg4/bin/getconf and /usr/xpg6/bin/getconf > (which are build from the same sources as /usr/bin/getconf (only using > different build flags)) - how should we deal with these binaries ? > Create another set of AST libraries compiled for specific for XPG4 ? > What happens if we get a XPG8 or XPG10 some day ? > > ---- > > Bye, > Roland > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20070117/41ac30aa/attachment.html>
