Talk:Thunderbird/StatusMeetings/2008-06-03
From MozillaWiki
<KaiRo> how do I run another python script from a python script (calling mozilla/client.py from ./client.py) <KaiRo> ? <ted> KaiRo: two options <ted> 1) you can just use os.system to run it like any other command <ted> 2) depending on how the script is implemented, you might be able to import it as a python module and call its methods directly <Standard8a> KaiRo: there's an example of 2 in bug 427980 <KaiRo> ted: well, it's actually a modified copy of mozilla-central's client.py calling mozilla-central's client.py <KaiRo> ted: at least for now, in testing, as long as the latter pulls in further code (I should call it with --skip-mozilla) <Pike> KaiRo: you could do something similar to http://mxr.mozilla.org/mozilla/source/tools/buildbot/buildbot/master.py#470 <Pike> or nag the gods of client.py to make it a proper python module and to use a if __name__=='__main__' foo at the end <ted> KaiRo: yeah, if vlad has his way we might get rid of client.py completely <ted> so you might want to hold off for a little bit <proxyvictim> shivu1: that's a debugger specific term <ted> he's planning on importing snapshots of NSS/NSPR into mozilla-central <proxyvictim> i'm not thinking in gdb right now :) <Pike> ted: and then we'll just have client.mk again? <Pike> for configure and build? <ted> yep <ted> no need for a separate checkout step <proxyvictim> complexity-- <Pike> is :bs still dreaming of rewriting that? <proxyvictim> ! <ted> we'll have to work out some l10n thing, but y'know <proxyvictim> ug <ted> Pike: yeah, we actually have a branch with a little bit of work <proxyvictim> pop complexity <KaiRo> ted: I'm just trying to get something up s I can test how a build process could work with structure that benjamin proposed to us <Pike> ted: comments welcome, http://wiki.mozilla.org/User:AxelHecht/l10n_for_3.1, same for KaiRo <ted> KaiRo: i hear you, i'm just saying i wouldn't spend too much time worrying about client.py, so just hack something to get it working for now <KaiRo> ted: and I thought it's easy to just call that client.py for now, and it's easily removed again later <proxyvictim> Pike: can you not leave punctuation after links? my irc client and mdc do the wrong thing :( <ted> KaiRo: right, that shoudl work <Pike> proxyvictim: bad client <proxyvictim> Pike: it's running on landfill. <KaiRo> ted: I still don't fully understand the reasons for not dynamically pulling nspr/nss but merging them into mozilla-central <ted> KaiRo: well, it's one less step for people to do, so less complex <KaiRo> ted: as if that's such a good thing to do, why should SeaMonkey not just merge mozilla-central into our own repo? <ted> if we merge snapshots, all you have to do is clone the hg repo, and you're ready to build <ted> KaiRo: well, the other side is that we already use fixed tags for NSPR/NSS, so it doesn't change much <ted> you could certainly pull m-c into your seamonkey repo, but you'd have to update it every time you wanted to pick up new checkins <ted> so if you wanted to track trunk, that might be painful <KaiRo> ted: true, that's my main argument against it as well <ted> for NSPR/NSS, it works, since we don't change the tag all that often <KaiRo> but I think making repos bigger by importing static code is not the best idea - we excluded lots of stuff from mozilla-central to trim down the repo size, now we're adding lots of stuff again <ted> well it's a tradeoff * KaiRo still thinks it was an error to include anythingy else than the platform in mozilla-central, fwiw <ted> KaiRo: i think unfortunately we're in a situation that nobody predicted <ted> m-c was supposed to be for moz2 development, and now it's going to have 1.9.1 <ted> so it puts you guys on the spot <KaiRo> yes, I'm also not in agreement with that decision <KaiRo> but I have to follow it <KaiRo> restrucutring SeaMonkey code for a Gecko dot-release is not what I had in mind, but whatever, we should better get used to it <ted> let me know if there's anything i can do to help <KaiRo> ted: well, there's a lot where I can need help, esp. how our configure.in and whatever starts the make (client.mk?) should look like <Standard8a> Mossop_sheriff: I'll check in a fix in a couple of mins if that is ok with you then? <KaiRo> ted: I have no real knowledge of configure.in stuff, so that's hard for me to set up <ted> KaiRo: yeah, i hear you <ted> hm <KaiRo> ted: you know the basic structure I'm working with, right? * ted wonders if bent's --enable-application stuff will let you use an application from a different srcdir <ted> KaiRo: no, how do you have things setup? <KaiRo> ted: http://wiki.mozilla.org/SeaMonkey/1.9.1_Repository_Options option A <Mossop_sheriff> ted: I keep meaning to test that <ted> Mossop_sheriff: if that doesn't work, i wonder if we could make it work <ted> because that would be cool <Mossop_sheriff> We should <KaiRo> ted: what I have now is a client.py that gets me mailnews/ and suite/ (for now pulling from cvs, for testing) next to mozilla/ (from mozilla-central) <ted> KaiRo: ok, sounds reasonable <ted> KaiRo: so this side conversation i'm having with mossop <KaiRo> ted: oh, and it pulls a chatzilla into extensions/irc <ted> i'm wondering if you couldn't just run mozilla/configure --enable-application=../suite <Pike> I doubt it <ted> i would bet that doesn't work <Mossop_sheriff> That won't help with the mailnews and other bits outside of suite though will it? <ted> well presumably the bits in suite would specify what else needs to be built <Mossop_sheriff> Actually I really don't think it would work <Pike> my take was that you need to teach all the makefiles in mail/mailnews that they're having a new DEPTH or something <Mossop_sheriff> yeah <ted> ah, yeah * ted ponders <Pike> and then make tier_whichever in mozilla and then use a different makefile to build the rest and link it <ted> it seems a shame for SM/TB to have to replicate the build system <ted> which is already sitting there in mozilla/ <Pike> not sure they have <ted> with support for building arbitrary stuff <KaiRo> yes, we'd probably need our own client.mk running the Mozilla build and then building our own stuff <Mossop_sheriff> What is wrong with having suite inside mozilla? <Pike> what KaiRo says <KaiRo> Pike: well, the other option is to create at least three repositories for SeaMonkey and Thunderbird, not mentioning those for extensions we pull in in any case <ted> Mossop_sheriff: i don't know that you can do that with hg quite that way <ted> at least not with pulling the suite bits first <Mossop_sheriff> Oh <Mossop_sheriff> No you can't <Pike> ted: but you could do it in the optdir :-) <Pike> I bet that works <ted> optdir? <Pike> if you can trick suite/makefiles.sh to do the right thing <KaiRo> Mossop_sheriff: we need at least mailnews/ and suite/ in our repo, we probably even want to share the repo with Thunderbird (as we share mailnews/) <ted> hum <ted> KaiRo: so, here's what i'm thinking right now <ted> we just add some options to client.py to make it able to pull the seamonkey/thunderbird bits for you <bhearsum> stupid question: why can't mailnews be in its own repo, and pulled in for suite/tb builds (same way we currently pull in tamarin-central for m-c builds) <ted> then you just clone m-c, run client.py, and build <ted> KaiRo: how does that sound to you? <KaiRo> bhearsum: it sucks doing cross-commits to all three dirs <bhearsum> why would you have to cross-commit? <bhearsum> i mean "pull in at build time" <ted> we could pull them from CVS for now <ted> and mercurial later, or whatever you want to do <KaiRo> bhearsum: and changing mailnews/ stuff often needs changes in both mail/ and suite/ at the same time <ted> KaiRo: if we just pull them from CVS for now, you don't have a problem, right? <bhearsum> ah <ted> then you can work out a cleaner solution later <KaiRo> ted: this would probably be easiest for now, but it doesn't solve the matter of having a furute in hg <ted> but at least it gets you up and running on 1.9.1, with the mailnews/suite stuff in CVS <ted> right <ted> i'm looking for a quick path to get you guys up and tracking the trunk <KaiRo> yes, for that matter, it probably sounds good <ted> ok <KaiRo> and we can work on the "right" solution for moz2 then <ted> yeah, or later down 1.9.1, depending on your schedules <Standard8a> oh great <ted> it doesn't really matter, it's up to you <Standard8a> so does that mean I won't be able to pull hg 1.9.1 and have my cvs repository in hg ? <KaiRo> Standard8a: how does that sound for you? if you agree, we should probably bring this up in today's TB meeting <ted> Standard8: sorry, what? <Standard8a> ted: whatever happens I'd like to use hg with /mailnews and /mail dev <KaiRo> Standard8a: I guess on Linux and Mac at least you can do symlink tricks for that for now <Standard8a> KaiRo: I think we should definitely put it on the agenda <Standard8a> ted: so I suppose we could make the client.py command flexible so that we could pull /mailnews etc from a local hg dir rather than cvs <KaiRo> Standard8a: of course, we can work on fully going for hg right now, but ted's solution would enable us to build on 1.9.1 right now and move our sources to hg in our own timeframe =-= Mode #developers +o mkaply by ChanServ <KaiRo> (at least the official copies, local repos are a different matter) <Standard8a> KaiRo: yeah, that's fine, I'm saying I'm using hg + cvs at the moment, and I'd like to keep using hg for the mailnews bits even if we do this merged solution <ted> Standard8a: as far as i'm concerned, you can make it do whatever you want <KaiRo> sure, that would be nice <Standard8a> ok, so who's doing what? <KaiRo> Standard8a: I'm pretty sure you can place your own copy of stuff there and run client.py with --skip-mailsuite or so <ted> KaiRo: as i said, we'll probably be removing the requirement to run client.py at all for firefox development <Standard8a> KaiRo: well actually I'd like --use-localhgmailsuite=dir <jorendorff> Interesting... my Vista VM won't boot <Standard8a> or something like that <ted> Standard8a: that'd be a bit different <ted> since the build system would have to know how to deal with that <KaiRo> ted: yes, right <jorendorff> I can revert to a snapshot, and it'll run, but it notices there are updates to install, and when it installs them and reboots, it doesn't come up. * jorendorff downgrades to XP <bhearsum> you could just hg clone the local copy, couldn't you? <Standard8a> ah but could I clone it into the same directory? <bhearsum> oh, right <ted> if you don't run my proposed client.py command at all, you can do whatever you want * KaiRo just created the "mailsuite" name today for naming his Thunderbird+SeaMonkey repo work ;-) <ted> symlink, copy, check out a separate repo <ted> anyway * ted files a bug on his proposed solution <Standard8a> yeah it'll probably have to be symlink <Pike> I think that conceptually, you should clone tb-sm-central with mail and mailnews and suite (as those teams see fit) <Pike> and then pull in mozilla-central into that, by it's own client.py for now, up to teh point where forrests stop sucking <Standard8a> I think that's probably already agreed <Pike> ted: CC me? <KaiRo> ted: pleas cc kairo@ <Standard8a> but moving to hg isn't agreed yet <ted> will do <KaiRo> Pike: yes, that's what I was trying to work on (following http://wiki.mozilla.org/SeaMonkey/1.9.1_Repository_Options option A) <KaiRo> Pike: but it probably needs our own configure and client.mk and might need some interesting changes to build stuff, including L10n <ted> what's davida's bugmail? <KaiRo> Pike: I have a client.py to do that already, but everything else is still up in the air <Pike> KaiRo: I'd start out by getting tier_toolkit built, via a client.mk <Pike> ted: yeah, me too. :Pike works <ted> will have to re-train my brain there <Pike> ted: feel free to tell simon to get out of your habits. I'll pay entrance fee and watch ;-) <KaiRo> Pike: don't I need configure before client.mk? <ted> heh <Standard8a> KaiRo: shall I add to the status meeting page? <ted> it's bug 437059 <ted> for anyone interested that i didn't CC <biesi> KaiRo, client.mk runs configure <KaiRo> Standard8a: yes, I think that would be good <KaiRo> biesi: ah, right <ted> client.mk doesn't know anything about tiers though <Pike> KaiRo: yeah, I think that if you do the right thing with makefiles.sh, you could use the standard configure <Pike> and if not, extend that to work <biesi> ted, that's not really true <biesi> it knows how to check them out doesn't it? <ted> not in mozilla-central <biesi> oh, ight <biesi> right <KaiRo> Pike: hmm, I'll look into that <proxyvictim> KaiRo: can seamonkey live as a single sub dir under mozilla-central? <ted> make -f client.mk build pretty much just does "make -C OBJDIR" <KaiRo> proxyvictim: not without 1) major restructuring and 2) ending the sharing of mailnews/ with Thunderbird <proxyvictim> if so, we could probably have a couple of integration points where it does for each (dir in foo/ ) (cd $dir; hg pull) <proxyvictim> KaiRo: could mailnews/ live in its own repo? <Pike> ted: I wonder, aren't the app tiers in the app dir already? <ted> Pike: yes <ted> that was what i was musing about earlier <KaiRo> proxyvictim: theoretically, yes, but then we would have problems with a change in mailnews/ mail/ and suite/ being practically one changeset, which happens quite often <bsmedberg> ted: did a particular convesation cause bug 437059? KaiRo and I were discussing it Friday <ted> bsmedberg: yes, we were discussing things right now <KaiRo> bsmedberg: we just discussed this today <bsmedberg> did you all see http://wiki.mozilla.org/SeaMonkey/1.9.1_Repository_Options ? <ted> bsmedberg: that was my idea, i think it's the simplest path to getting them building against 1.9.1 <ted> yes * bsmedberg hopes KaiRo got his mail <bsmedberg> ted: yeah it might be, though it makes me sad <ted> and i think they should get to a better solution <KaiRo> bsmedberg: yes, I pointed ted to that... actually, I already have a client.py for option A, and that spawned this discussion here <ted> bsmedberg: right, but i think we also threw them a curveball with 1.9.1 being in hg <bsmedberg> The hard part of option A is writing a new configure script <ted> bsmedberg: so the side conversation that came out of that <ted> could they have m-c live in a subdir of their repo, but still use the normal mozilla build system? <bsmedberg> ted: I'm wondering if there's not a way to put this checkout script into the seamonkey/tbird repo, instead of the gecko repo <ted> bsmedberg: yeah, i thought about that a little bit, and while it may lack theoretical purity, it will definitely work <bsmedberg> ted: I can't think of an easy way to do that, but I might lack imagination <biesi> configure scripts aren't so hard to write <bsmedberg> ted: maybe --enable-application=.. ? <biesi> simple ones aren't anyway <ted> bsmedberg: right, i was wondering if that works <ted> might need some tweaking of mail/suite/mailnews <ted> but that might be ok if they wound up in a hg repo <Standard8a> this is almost xulrunner + an app, the problem is that we still need to configure core quite a bit <ted> even if you were using a xulrunner sdk, you'd still want the build system <Standard8a> true <ted> that's what i'm thinking, it's silly to not be able to use our build system <ted> which already knows how to build your stuff <Pike> ../suite might actually get pretty far <ted> i think if that doesn't work, we should make it work. <Pike> agreed <ted> unless there's some real horrible technical reason it won't <ted> make a mailnews-central or something, with mail/mailnews/suite dirs in it <bsmedberg> make-makefiles might get confused <bsmedberg> because srcdir is "above" topsrcdir <ted> right <ted> may need some handwaving <proxyvictim> err <proxyvictim> you guys know that netscape used to have something like that... <bsmedberg> yes, in the long-lost past <proxyvictim> did _you_ break it? :) <bsmedberg> most likely, yes <shivu1> proxyvictim: the gcLock was 0x1 always... <bsmedberg> but if that directory structure works, then seamonkey/thunderbird can either use forests or client.py in their repo to stitch things together <ted> yeah <proxyvictim> shivu1: hrm... interesting <ted> which gets them into a decent future <proxyvictim> ask #jsapi ? * Standard8a tries * shivu1 was not aware of that channel <jorendorff> stuart: ping <ted> Standard8a: it's certainly not going to work out of the box <Standard8a> ted: just interested in how far it gets <ted> for one thing, the dirs living above mozilla/ will have DEPTH wrong <ted> Standard8a: file a bug with your results <sdwilsh> is there a way to tell if a window has focus? <jorendorff> stuart: I want to put that Mercurial chat session on my blog, just change the names and delete some of the boring parts. Do you think that's ok? <Standard8a> ted: and mozilla-central doesn't have extensions <Standard8a> or rather wallet <ted> that's probably work-aroundable <bsmedberg> that code should live in mailnews or suite or something <bsmedberg> I'd like to vacate extensions/ completely <ted> yeah, it doesn't have to live in extensions/ whatever <Standard8a> we should actually just replace it <Standard8a> which is on my queue <ted> well yeah <ted> but to get you working again <ted> you could stuff it somewhere else
