On Wed, Feb 27, 2008 at 11:47:07AM -0800, mike.sullivan at sun.com wrote: > >From Nicolas.Williams at sun.com Wed Feb 27 11:33:07 2008 > > >> You do either way :) And I'd think that this part of the work is > >> the easy part of doing upgrades. After all, if the Makefiles can > >> be told to install into $ROOT properly then pkgmk and protocmp will > >> notice when things are added/removed. When you have a hardcoded list you > >> won't know unless something is deleted, and it will still be easy > >> for you to miss, say, a new header file that needs to be shipped > >> because an existing one now requires it. > > > >I still have the problem that I have to run *two* configure && gmake > >installs, one for 32-bit and one for 64-bit and I don't want to have to > >make sure that they don't step on each other (there's lots of paths to > >check). > > well that might be a good reason - if it might put the 64-bit library > in /usr/lib because it's not expecting our subdirectory setup then > I understand cherry-picking from the 64-bit version. And at least that's > confined to 64-bit executables/objects.
There's the headers too. > >Folks, I'm trying to make things simple. And all I see is complications > >arising here. I find it a lot simpler to install into a tmp DESTDIR and > >cherry pick. I'll stick with it unless someone pulls rank (Mike, I > >guess that'd be you :) > > Well I think I require you not putting your tmp DESTDIR in the proto > area. I'd rather the 32-bit build not use the tmp DESTDIR, but I'm > tired now (I think that's a record even when I'm not sick). Yes, this I've just fixed (webrev not yet updated). I'm tired too. Get better. I'll publish a new webrev soon. Yes, I've rejected some comments. I'll keep the install-sfw DESTDIR thing, and fix_elf_runpath(). > >BTW, I've put many hours into trying this various ways, and over the > >weekend too. I really, *realy* don't want to experiment anymore before > >integrating. Think of future volunteers. > > Hmm so I guess I have to ask - isn't that you, since you will be supporting > it? Or perhaps I'll see the answer in the C-team checklist? Since I > know you're not putting it back then letting someone else support it :) I was thinking of future volunteers to integrate *other* things. This code review has taken enormous amounts of energy for me. I can't keep this up folks, not when I have a day job (including a pending P1 CR fix to putback into ON, several code reviews on which I'm late, etc...). Folks, please stop picking on things that aren't ideal but which _work_. Clearly there will be lots of issues, for future SFW components, like the ones we've discussed in this review, so coming up with a useful set of guidelines would be nice, but let's do that separately from this code review. Nico --
