>>>>> "Roland" == Roland Mainz <roland.mainz at nrubsig.org> writes:
>> I'd like to see a makefile fragment that just has the stuff that >> needs to be the same. Roland> Yes, but is it reallly a justification to create such a file Roland> because there are only two common locations in Makefiles ? My experience is that it's more reliable to set things up in a way that makes it easy for people to do the right thing. (In this case "right thing" means "keep the -D/-U list the same"). That said, I would just recommend, not require, a single makefile fragment. Roland> There are like other locations in other Makefiles for which the Roland> same "rules" would apply then... No doubt. There is a lot of cruft in the sources. The point is not to add to it. Roland> On the othe hand there is "shcomp" (the shell script to ksh Roland> bytecode compiler) which would need the same set of flags [...] Roland> making this three locations... the question is whether we do it Roland> "now" or when "shcomp" hits OS/Net ... My vote is for now, though again, that's just a recommendation. Currently, I'm more interested in resolving any issues that are keeping us from putting ksh93 binaries up on opensolaris.org. >> >> * usr/src/cmd/ksh/Makefile.com >> >> - install target: why add the "set -x"? Roland> From ksh(1): Roland> -- snip -- Roland> -x Prints commands and their arguments as they are executed. Roland> -- snip -- Roland> The basic idea is to see which exact command failed when a Roland> problem occurs. >> Okay, I thought it might be something like that. I'm concerned about >> extra noise in the build and having to add something to nightly.sh to >> filter it out. But I'm okay with leaving it in for now and seeing if >> it's really a problem or just my paranoia. ;-) Roland> Erm... why should this extra output be bad ? More detailed build Roland> logs are not evil... :-) If it only shows up in nightly.log, it's not an issue. If it shows up as "noise" in nightly's mail message, then it means every ON developer gets to spend time figuring out if the message is something they need to worry about. That's potentially a lot of wasted time. Like I said, I was probably just being paranoid. We can leave it as-is. >> >> * usr/src/lib/libshell/common/Makefile >> >> usr/src/lib/libdll/common/Makefile >> >> usr/src/lib/libast/common/Makefile >> >> - I think that having these files in the ON tree will cause >> >> confusion. I'd like either to remove them or explain in >> >> README's that this file is not used for ON. Roland> Added to my ToDo list (killing them is an option, but the next Roland> diff between ksh93 and Solairs sources then list these files as Roland> "missing" and the person who does the update then has figure out Roland> the "why ?". >> Hopefully this would be less of a problem once we have everything >> under Mercurial. Roland> Erm... how should Mercurial be able to help in this case ? Well, when you're doing an update using diffs and a file is missing, the question is "was the file added in the upstream version, or was it removed in the downstream version". When we have everything under Mercurial, the answer will be clear: it's because we deleted it from the downstream version. >> >> I see that the workaround hack for the PAGESIZE redefinition is >> >> still in place. This will need to be changed prior to putback. Roland> I'll try to fix that after the next ksh93r+_alpha*-update - is Roland> that Ok for you ? Sure; I think the only requirement is "before putback". >> By the way, thanks for the fine-grain checkins and the pointers to >> the changeset web pages. That makes it much easier to review >> specific changes. Roland> Yes... I wish we could move these changes and their comments Roland> into OS/Net without loosing the whole history... any ideas Roland> whether this is possible somehow? Not with Teamware. And not with the current version of Mercurial, I believe. I suppose we could put an archive copy of the Subversion repo on a server somewhere. mike
