Re: [pyxpcom] XULRunner + PyXPCOM
by Paul Everitt other posts by this author
Jan 24 2008 4:31AM messages near this date
view in the new Beta List Site
Re: [pyxpcom] XULRunner + PyXPCOM
|
Re: [pyxpcom] XULRunner + PyXPCOM
On Jan 23, 2008, at 11:59 PM, edward baafi wrote:
> Paul,
>
> Two bounties are better than one.. But I guess I have two questions:
>
> 1) When you say "Something capable of building a binary at one
> point, on all 3 platforms, at the time of the bounty, would be
> enough" I'm still a little confused.. Are we talking about pyxpcom
> building on the trunk on a particular day or some branch or tag like
> 1.9b2? If one was to patch the heck out of the trunk or some branch
> to get it to build, and supplied the diffs, would you push those
> patches and pay the bounty or would you expect the bounty hunter to
> push the patches?
At this stage, maintaining the patches separately (as ActiveState is
doing) is ok.
At some point, PyXPCOM either becomes "supported" or its appeal might
wane. But solving that problem in the first step is not reasonable.
If the first and second bounties help gather a small group of people
that, with some risk, can count on it, then we might get enough
momentum towards the longer solution.
> 2) I guess this is a question for everybody: I like the idea of a
> pyxpcom extension but have only explored this for Firefox.. So what
> is the fundamental difference between a Firefox and Xulrunner
> extension where FF and XulRunner are from the same codebase? Also,
> I'm wondering if we built the pyxpcom extension from some branch
> like 1.9b2, what is the likelihood that it would work with an
> arbitrary nightly xulrunner build? (ie - how isolated is the xpcom/
> python code from the rest of the beast?)
Just to be clear, I want the ability to make a self-contained
executable like XUL Explorer. I don't know if xulrunner extensions
are a way to do that for pyxpcom.
--Paul
>
>
> Thanks,
>
> Ed
>
> On Jan 23, 2008 7:50 PM, Paul Everitt <paul@[...].com> wrote:
>
> On Jan 23, 2008, at 7:17 PM, Mark Hammond wrote:
>
> >> Regarding the comments about which build system, I agree with Mark
> >> that we
> > need to
> >> converge on one. I won't prejudice the choice. Mark obviously has
> >> 99% of
> > the
> >> history on this, but Todd mentions some gaps that he is interested
> >> in.
> >
> > Just to clarify, I believe we are no longer talking about just a
> > *build*
> > system, but instead a *packaging* system, along with some kind of
> > commitment
> > to create binaries using that system? Specifically, the script of
> > mine and
> > I assume the pyxpcomext project use the standard build process.
> >
> > Even more specifically, to have solved your (Paul's) problem, this
> > system
> > must also be capable of generating binaries for Windows, Mac and
> > Linux, and
>
> Just to clarify, I realize this bounty isn't big enough to get a
> buildbot-like process on autopilot on all 3 platforms. Something
> capable of building a binary at one point, on all 3 platforms, at the
> time of the bounty, would be enough.
>
> > will presumably need access to that hardware. Its is probably *not*
> > enough
> > to simply confirm (say) Mac builds work, then assume they will
> > continue to
>
> I think that's the rub. For pyxpcom to have a future for people like
> me, it needs to be easily built, and stay easily built. I'm not sure
> anybody is committed to the latter. Perhaps I'm seeing things the
> wrong way?
>
> --Paul
>
> >
> > work in the future, and assuming people could simply make their own
> > using
> > that process. As we saw, that would have fallen over at the first
> > hurdle
> > (the building of it) in the case of Paul. So I guess I don't see
> > exactly
> > what deliverables you are expecting for this bounty, and how they
> > would have
> > saved your bacon had they been put in place 12 months ago.
> >
> > In general though, I've absolutely no problem with pyxpcomext being
> > the
> > official package. I was a little dissapointed to have not heard
> > about the
> > effort and that opportunities aren't taken to collaborate on things
> > ("not
> > invented here" syndrome?). Certainly pyxpcom can only benefit from
> > having a
> > functioning, supported distribution.
> >
> > Cheers,
> >
> > Mark
> >
> >
>
> _______________________________________________
> pyxpcom mailing list
> pyxpcom@[...].com
> To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
>
Thread:
Shane Caraveo
Paul Everitt
Jesus Cea
Shane Caraveo
Paul Everitt
Edward Baafi
Shane Caraveo
Paul Everitt
Paul Everitt
Mark Hammond
Todd Whiteman
Paul Everitt
Edward Baafi
Mark Hammond
Paul Everitt
Todd Whiteman
Mark Hammond
Shane Caraveo
Todd Whiteman
Edward Baafi
Todd Whiteman
Mark Hammond
Todd Whiteman
Edward Baafi
Todd Whiteman
Shane Caraveo
|