Roland Mainz wrote: >> The fact that it's not public is a bug which is being worked. For one-off >> scripts used to generate files, I don't see a need to have that version >> controlled. However, if you do, then just put a URL to the SCM-controlled >> version in the CR. Like I said above, put the script wherever you want, >> as long as it's not in the source tree.
No, no no. No. Put the goddam thing in the source tree. If you want to quote precedent, quote the stuff under the perl usr/src/cmd/perl/5.8.4/utils directory. As long as it's clearly separate from the source that gets built, and there's a README that says what it's for, I can't see there is a problem. > Now I am getting VERY nervous while thinking about the "buildksh93.ksh" > script. Most other sources/bits can be regenerated with some diff, hacks > and lots of time... but if that script gets lost or out of sync we can > rm -Rf the whole ksh93 sources in the tree and restart from scratch at > the last snapshot point (if there is one). That's why I don't like the > idea of a different location outside the tree. I remeber the issue about > the IPv6 patch for dtksh and I really never want to be in this hell with > that script since we cannot recover from that problem without lots of > time (yes, yes, OpenSolaris will try to avoid the mistakes of the > past... but unlike the IPv6 bits for dtksh (which can be described as > some obscure moulding on a balcony in a far corner of one of the smaller > towers) this one sits near the headstone and loosing such stuff may > collapse the whole thing by accident. That's why I am sitting here now > and can't really sleep... ;-( ). You are right to be concerned. Check it in. >> It seems reasonable to me to strip out any files that will never be used >> by ON. That would include the Makefiles and files that are exclusive to >> other platforms (e.g., workarounds for brokenness on other platforms). We >> have a tool (findunref -- through the -f option to nightly) that will >> automatically identify all files that aren't accessed during the build. >> >> In general, all putbacks to ON must be findunref-clean, but exceptions are >> granted for code that we plan to keep in-sync with an upstream source. > > What do you mean with that ? Would this apply to our AST/ksh93 codebase > (I am praying for that (it seems at least "perl" and "BIND" fall into > this category)) ? As I said, if you put all your porting goop into a seperate directory, it's easy enough to add it to findunref. -- Alan Burlison --
