On Tue, 2006-07-25 at 22:16 +0200, Enrico Weigelt wrote: > * Martin Schlemmer <[EMAIL PROTECTED]> schrieb: > > <snip> > > > > build or unpack both nspr and nss and then look whats laying around > > > there. the nss sourcetree contains the nsprpub tree. > > > > > > > Yes, but we don't install it with the nss ebuild, as our build uses > > system nspr. I am sure you could check with upstream, but they will > > probably say its intended as nss needs nspr if I remember correctly. > > So the nspr subtree in nss is dead code (for gentoo) ? > Then we better should remove it - just to be sure ;-) >
Uhm, so you want us to re-tarball it instead of just using the tarball from upstream? How about firefix, seamonkey, xulrunner (I think), thunderbird, sunbird, etc ? Should we re-tarball those as well? > BTW: it seems both nspr and nss are not really standalone packages, > but instead snippets from CVS which requires much manual interaction > (which is done by the ebuild). IMHO it would be worth investing some > time into making both nspr and nss standalone packages with clean > pkg-config, etc. Although I dislike autotools for some reasons > (ie. crosscompiling is very ugly) we could use it until something > better is available Sure, but you are still missing the point that it comes so from upstream. You can take the effort, but it will need to be OK with upstream to really make it worth the effort, else it might become a high maintenance item. Anyhow, that is the whole issue with mozilla stuff in general - huge hunk of code that is not really modular, and have to be rebuild for a few to many projects. While I am all for getting the POS more modular (which we at least did for nspr and nss), you will need to get cooperation from upstream, as they used to give a rats ass about abi compatibility when I was more involved with it, and loads of time if you actually want to try and do it yourself (which is more than I have currently), plus even more courage, as currently it will need to be done for probably at least 6-12 projects (nss, nspr, suite, browser, mail, minimo, composer, calendar, xulrunner, macbrowser, standalone, maybe chat, etc). So if you have time, courage and the drive to do it, be my guess, but know that it will be a project of some months of work, if not years. > (in fact I'm working on my build tool ...). > Something Xorg-modular ;-) Many distros would benefit from that. > Not sure how this relates at to us, but as they say, code speak louder than words. Regards, -- Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
