Craig Mohrman wrote: > There are a source files (*.h and *.c) under the architecture specific > directories of the major components: > > usr/src/lib/libast: > amd64/include/ast/ast_limits.h > i386/include/ast/ast_limits.h > sparc/include/ast/ast_limits.h > sparcv9/include/ast/ast_limits.h > for example.
Yes, this is why these autogenerated sources are not in common/ - these are headers and sources created by "iffe" during the normal AST build and then copied over into the OS/Net tree into the ISA/platform-specific subdirs. This was intentional done by design. BTW: The "public" includes are handled by a mechanism which folds these includes into a unified version, see usr/src/lib/libast/Makefile.astinclude which is a Makefile fragment which post-processes the includes and folds them into one version where the content is #ifdef'ed per platform/+ISA. > Some of these files contain values from the underlying OS headers and > if those values change then these sources would not detect that because they > are now hard coded and not autogenerated. Correct - but see below... > Don and I believe these files need to be autogenerated at build time > and not hardcoded the way they are. > Can you change this please? Not really. We've looked at the problem in the past multiple times and doing that would open a whole new "can of worms". Some problems: - We can only generate these files when the OS/Net build is complete and we can't rely on the underlying build system since it may not be in sync with the OS/Net tree. - Updating the files for each build is dangerous since this may cause bugs to appear and disappear "randomly" based on the build environment. We would get lots of "heisenbugs" and increase the test matrix by at least another dimension of unknown size. - We would have to develop our own version of the "iffe" tool with extended capabilities such as probing the proto area (which the original does not have) - this would more or less result in a rewrite/adjustments of the whole probe/test machinery (short: at least four months/person of work would be required and each update from upstream will require lots of manhours to adust our probes for each update) - We would have to explain and convince gatekeepers that having a autoconf-style feature-probing system is a good idea (AFAIK the current response goes into the direction of "only over our dead remains"...) AFAIK it is much better to follow the current design and just "update" the autogenerated files for each update from upstream - that would "catch" all changes in OS/Net propperly (and it would reduce the test matrix since the matching autogenerated headers and sources only change at these updates and not "randomly" for each build). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
